[builder] Access to information generated during doExpand()

[kriegfrj]

Executive summary

In looking at #3175, I have done a deep-dive on the Bnd builder/analyzer and it seems that the Analyzer generates (nearly) all of the information that I need to make this work well. Unfortunately, it overwrites the necessary information before the caller can get its hands on it.

Detail

The problem

Suppose I have have two projects:

• local-proj, which has the package my.local.ws.pkg as a private package;
• other.proj.one, which has two source packages some.priv.pack and some.exported.pack and a bnd.bnd file like this:

-buildpath: local-proj
-privatepackage: some.priv.pack,my.local.ws.pkg
Export-Package: some.exported.pack;version=1.2.3

Project.build() ultimately calls doExpand(), which builds up the contents of contained so that it has the full list of packages that the Jar-under-construction will ultimately contain. After doExpand() is called for project other.proj.one, the contained field looks like this:

some.priv.pack;-internal-source:="other.proj.one-0.0.0",my.local.ws.pkg;-internal-source:=local-proj-0,some.exported.pack;-internal-source:="other.proj.one-0.0.0"

Thus the -internal-source: directive on each entry correctly identifies the project that each package came from. This is the information I need to correctly build up the correct set of transitive dependencies for #3175.

However, after completing the expand phase, Project.build() then calls calcManifest(), which in turn calls analyze() -> analyzeBundleClasspath() -> learnPackage(). dot is passed as the Jar parameter to learnPackage(), so when this code runs:

https://github.com/bndtools/bnd/blob/dbf5fb4ddbb5ca0d2cc3292bdff0433e4f781949/biz.aQute.bndlib/src/aQute/bnd/osgi/Analyzer.java#L662-L706

...then the -internal-source: directive is overwritten with the result of getName(jar) - which evaluates to dot-0.0.0. Thus the useful information that I was after is overwritten.

The first lines above seem to attempt to bypass the setting of -internal-source: if it is already set "in the manifest". I'm not sure how it could be triggered.

The solution

I'm unsure of the best solution, as I'm not sufficiently familiar with the intent of the code in learnPackage() and friends. Here are the possible solutions that I can see:

1. Modify learnPackage() so that it doesn't overwrite -internal-source: if it's already present. I'm just not sure what effect this has on code that comes after.
2. Add an "expand()" event to the OnWorkspace event bus that is called after the expand phase but before the analyze phase, which provides a snapshot of the artifact info before it is destroyed by analyze().

Thoughts?

[pkriens]

just create a new attribute that gets set when the first one is set?

I think no overwriting is not a big deal but by looking who use the attribute you should be able to get a fair idea who uses it. Doubt there is more than one use case.

[pkriens]

@kriegfrj I can fix the issue for you but would that still be useful for you?

[kriegfrj]

Yes, it would be useful I think. If I can get #3175 working at some point I think that would be very helpful.