Do not concat Bundle-Activator when already defined

[chrisrueger]

Closes #6867

fixes a problem that Verifier.verifyActivator() throws an error "The Bundle-Activator header only supports a single type. The following types were found" when the bnd instructions already define a Bundle-Activator but a processed jar also contributed a Bundle-Activator (e.g. via @Header(name = Constants.BUNDLE_ACTIVATOR, value = "${@class}") annotation).

see org.apache.logging.log4j.util.Activator

Before this fix the Bundle-Activator header was concatenated to the existing Bundle-Activator header in the outer bnd of the bundle and thus resulted in multiple values (separated by comma). But for Bundle-Activator this does not make sense as it supports only a single value, as there can only be one single Bundle-Activator in the manifest - which is correctly complained about by Verifier.verifyActivator().

This PR fixes the root cause where the multiple-values are created, so that Verifier.verifyActivator() does not complain anymore.

This for example happened with -includeresource of a Bundle (unrolling or lib:=true) or other ways where bnd scans classes of jar files.

I also identified some other Bundle headers in which should also only contain a single value and not be concatenated.

[chrisrueger]

Any thoughts @pkriens @peterkir ?

Do you think there are other headers too, which should have only a single value, if already defined? Or is Bundle-Activator the only header like this?

Update: Added a few other headers which only allow a single value

[chrisrueger]

Note: A related issue which touches a similar topic #5363 (and non-merged PR #5389 )

From there it also becomes apparent that Require-Capability & Provide-Capability are the main targets of that method.
That means, that the current fix is at least not wrong.

[stbischof]

plans to merge, what blocks?

[chrisrueger]

what blocks?

The lack of feedback. And the controversy in the issue discussion. I think the PR fixes the problem reported in the #6868 . If it fixes it in the best way - I don't know.

I will try to bring it up in the next bnd zoom call

[stbischof]

+1

[juergen-albert]

The Mechanism should also make sure, that any bundle activator header is not just a singlton, but that the property in the bnd file wins, so I can overwrite whatever included classfiles may define here.

[chrisrueger]

that the property in the bnd file wins, so I can overwrite whatever included classfiles may define here.

That is the exact purpose of that PR. But only for the properties in the new Set BUNDLE_HEADERS_SINGLE_VALUE I defined (which includes Bundle-Activator).

https://github.com/bndtools/bnd/pull/6868/files#diff-be27a5a501f05ec3c1bc10a14a8bed0592a76cd02407998f98792675cd2b60c5R153-R156

Is that what you mean? @juergen-albert

[chrisrueger]

I renamed the private variable to AnnotationHeaders.BUNDLE_HEADERS_ANALYZER_WINS and added some explanation. I hope this makes the intention clearer. Since it's all private people can come up with better wording in the future.

[stbischof]

Here is an example where i would use this

https://github.com/eclipse-osgi-technology/command/blob/main/all/src/main/java/org/eclipse/osgi/technology/command/all/Activator.java#L26