Trace instructions and build classpath at Builder.build()

[xtracoder]

I think the most common use-case the Bnd Tools are used is via some kind of plugin in build environment (MAVEN, Gradle, ...) The key point for investigation of integration problems is knowledge about parameters BND is invoked with by these plugins. Currently this is missing.

'Mock' implementation is below:

public class Builder extends Analyzer {
    ...
    public Jar build() throws Exception {
        trace("build");
        System.out.println(
                ("BND build props: \n" + getProperties()).replace(", ", ",\n    "));
        System.out.println(
                ("BND build classpath: \n" + getClasspath()).replace(", ", ",\n    "));

Additionally, in case plugin does not support turning trace 'on' in its configuration - default value should be taken from some environment variable.

public class Processor extends Domain implements Reporter, Registry, Constants, Closeable {
    ...
    boolean trace = Boolean.valueOf(System.getenv().get("BND-Trace"));

[bjhargrave]

I am not sure what the problem is here you are requesting a change for? What is the change you are requesting?

[bjhargrave]

As for tracing, the best thing a tool driving bndlib can do is set the bnd trace to the state of their log debug level. For example builder.setTrace(logger.isDebugEnabled()) See https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.gradle/src/aQute/bnd/gradle/BundleTaskConvention.groovy#L105 and https://github.com/bndtools/bnd/blob/master/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L104. Then if you put the tool in debug mode, you also get trace information from bndlib.

[xtracoder]

Re: I am not sure what the problem is here you are requesting a change for? What is the change you are requesting?

The problem is - I can't trace problems in 3rd party plugins for external build system which internally use Bnd because I don't know how they actually pass parameters to Bnd - 'documented behavior' and 'actual behaviour' is in many cases different.

By 3rd party plugins I mean

• MAVEN - http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html (source code: http://svn.apache.org/repos/asf/felix/trunk/tools/maven-bundle-plugin)
• Gradle - has native plugin, but it is very limited and it seems they do not have time to support/enhance it - https://docs.gradle.org/current/userguide/osgi_plugin.html
• 3rd party Gradle - https://github.com/TomDmitriev/gradle-bundle-plugin
• another one, this one i didn't try yet - https://github.com/jruyi/osgibnd-gradle-plugin

At least Felix's Maven Plugin does not have options to turn 'trace' on. Other - may or may not have. End users - are not happy with no way to trace their integrated behaviour :(

the change requested

1. allow turning bnd's trace 'on' even when containing plugin is not aware about that functionality
2. at the beginning of building of bundle - trace initial settings, something like

Hello, Bnd Tools are building your OSGI bundle with these settings:
Instructions and Properties:
----------------------------------
  -includeresource=...
  Bundle-ClassPath=...

Build classpath:
----------------------------------
   c:\user\name\.m2\repo\...\xxx-1.2.3.jar

PS: out of your comments I see that now Bnd also has Gradle plugin (not sure how long it is available publicly) - need to try it out too. I suppose documentation for it is going to lend here (http://bnd.bndtools.org/tools/gradle.html). 'dev docs' are here (https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.gradle/README.md)

[bjhargrave]

At least Felix's Maven Plugin does not have options to turn 'trace' on. Other - may or may not have.

You should file bugs against these requesting they provide debug information on how they are driving the bndlib API like the bnd maven and gradle plugins do.

1. allow turning bnd's trace 'on' even when containing plugin is not aware about that functionality

How would this work? If there is an env var, does it just set the initial default? So that when the bnd gradle plugin calls builder.setTrace(logger.isDebugEnabled()) and log is not debug, then trace is not on? Or does the env var always set the trace state so that if the env var is set, then builder.setTrace() is a noop?

The former makes the env var not very useful when a tool properly sets trace. The latter makes the setTrace method useless when the env var is set.

The tools really need to be in charge of deciding the value of the trace setting.

1. at the beginning of building of bundle - trace initial settings

The bndlib trace 'facility' is just write to System.out. This is not super well behaved when the tool driving bndlib has a proper logging facility as maven and gradle do. The tool knows how to log properly and it should be doing the debug logging. Of course, the tool could capture System.out from bndlib and write it to the log, but this wont necessarily be true for all tools calling bndlib. Also, if the tool does log the bnd settings, then having bndlib trace them will result in duplicate output.

PS: out of your comments I see that now Bnd also has Gradle plugin (not sure how long it is available publicly)

The bnd gradle plugin has been around since 2.4.0 in Nov 2014. The docs for using the plugin are at https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.gradle/README.md.

[xtracoder]

Of course, both the way to enable trace via env vars and output to System.out in trace are 'emergency' measures for problem resolution. Nor me nor someone else, I think, will need this in the daily build process. Therefore no need to architect it in the most elegant way, i would say - major intention is to have ability to identify problem when it is not visible externally what happens between some plugin and Bnd tools.

[bjhargrave]

bndlib should not do this for the reasons discussed above. Tools driving bndlib should log the parameters given to bndlib. This is what the bnd gradle and maven plugins do.