[PDE] update biz.aQute.bndlib and -util to version 6.3.0

[HannesWell]

This PR aims to update biz.aQute.bndlib and biz.aQute.bnd.util to version 6.1.0.

But this it requires the following OSGi packages that are not yet present in Equinox:

• org.osgi.util.function version 1.2.0
• org.osgi.util.promise 1.2.0
• org.osgi.service.repository 1.1.0

For the first two packages only in version 1.1.0 respectively 1.1.1. is present in Equinox (in the bundle org.eclipse.osgi.util).
The latter seems not to be included in Equinox at all (at least I could not find it in the rt.equinox repos).

I think we should not ship those packages with m2e, therefore I'll see what I can do in this regard in Equinox, but we have to wait for Eclipse 2022-03 M1.

[HannesWell]

According to clearlydefinied we have at least IP-clearance for these libraries:

[DEBUG] Filtered dependency artifact list:
[DEBUG]   biz.aQute.bnd:biz.aQute.bnd.util:jar:6.1.0:compile
[DEBUG]   biz.aQute.bnd:biz.aQute.bndlib:jar:6.1.0:compile
[DEBUG]   org.osgi:org.osgi.dto:jar:1.0.0:compile
[DEBUG]   org.osgi:org.osgi.framework:jar:1.8.0:compile
[DEBUG]   org.osgi:org.osgi.resource:jar:1.0.0:compile
[DEBUG]   org.osgi:org.osgi.service.log:jar:1.3.0:compile
[DEBUG]   org.osgi:org.osgi.service.repository:jar:1.1.0:compile
[DEBUG]   org.osgi:org.osgi.util.function:jar:1.2.0:compile
[DEBUG]   org.osgi:org.osgi.util.promise:jar:1.2.0:compile
[DEBUG]   org.osgi:org.osgi.util.tracker:jar:1.5.4:compile
[DEBUG]   org.osgi:osgi.annotation:jar:8.0.1:compile
[DEBUG]   org.slf4j:slf4j-api:jar:1.7.25:compile
[INFO] Querying Eclipse Foundation for license data for 12 items.
[DEBUG] EF approved: maven/mavencentral/org.osgi/org.osgi.resource/1.0.0 score: 100 Apache-2.0 #258
[DEBUG] EF approved: maven/mavencentral/org.slf4j/slf4j-api/1.7.25 score: 100 MIT CQ13368
[INFO] Found 2 items.
[INFO] Querying ClearlyDefined for license data for 10 items.
[DEBUG] Sending: maven/mavencentral/biz.aQute.bnd/biz.aQute.bnd.util/6.1.0
[DEBUG] Sending: maven/mavencentral/biz.aQute.bnd/biz.aQute.bndlib/6.1.0
[DEBUG] Sending: maven/mavencentral/org.osgi/org.osgi.dto/1.0.0
[DEBUG] Sending: maven/mavencentral/org.osgi/org.osgi.framework/1.8.0
[DEBUG] Sending: maven/mavencentral/org.osgi/org.osgi.service.log/1.3.0
[DEBUG] Sending: maven/mavencentral/org.osgi/org.osgi.service.repository/1.1.0
[DEBUG] Sending: maven/mavencentral/org.osgi/org.osgi.util.function/1.2.0
[DEBUG] Sending: maven/mavencentral/org.osgi/org.osgi.util.promise/1.2.0
[DEBUG] Sending: maven/mavencentral/org.osgi/org.osgi.util.tracker/1.5.4
[DEBUG] Sending: maven/mavencentral/org.osgi/osgi.annotation/8.0.1
[DEBUG] ClearlyDefined maven/mavencentral/biz.aQute.bnd/biz.aQute.bnd.util/6.1.0 score: 60 Apache-2.0 OR EPL-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/org.osgi/org.osgi.dto/1.0.0 score: 83 Apache-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/org.osgi/org.osgi.framework/1.8.0 score: 85 Apache-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/org.osgi/org.osgi.service.log/1.3.0 score: 85 Apache-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/org.osgi/org.osgi.service.repository/1.1.0 score: 86 Apache-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/org.osgi/org.osgi.util.function/1.2.0 score: 75 Apache-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/org.osgi/org.osgi.util.promise/1.2.0 score: 75 Apache-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/org.osgi/org.osgi.util.tracker/1.5.4 score: 75 Apache-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/org.osgi/osgi.annotation/8.0.1 score: 75 Apache-2.0 approved
[DEBUG] ClearlyDefined maven/mavencentral/biz.aQute.bnd/biz.aQute.bndlib/6.1.0 score: 60 Apache-2.0 OR EPL-2.0 approved
[INFO] Found 10 items.
[INFO] Vetted license information was found for all content. No further investigation is required.
[INFO] Summary file was written to: C:\dev\workspaces\eclipse.m2e\test.dash-tool\target\dash\summary
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  3.793 s
[INFO] Finished at: 2021-12-10T19:37:46+01:00
[INFO] ------------------------------------------------------------------------

[laeubi]

I think we should not ship those packages with m2e, therefore I'll see what I can do in this regard in Equinox, but we have to wait for Eclipse 2022-03 M1.

Yep that's a good choice, I don't think there is no need to rush here.

[HannesWell]

Updated to bnd.lib 6.2 and created issue eclipse-equinox/equinox#18 to discuss the update of the required packages.

[bjhargrave]

Please stop using Require-Bundle for bnd artifacts in m2e. You should instead Import-Package whatever packages you use. Bndtools also uses bnd artifacts and uses Import-Package to access the necessary packages. Require-Bundle has undesirable side-effects and should almost never be used. I am concerned about resolution issues when Bndtools and the m2e-pde feature are both installed. This could result in multiple copies of bnd artifacts being installed and resolved.

[HannesWell]

Please stop using Require-Bundle for bnd artifacts in m2e. You should instead Import-Package whatever packages you use. Bndtools also uses bnd artifacts and uses Import-Package to access the necessary packages. Require-Bundle has undesirable side-effects and should almost never be used. I am concerned about resolution issues when Bndtools and the m2e-pde feature are both installed. This could result in multiple copies of bnd artifacts being installed and resolved.

Yes, we should not do that.
Furthermore we should actually not include bnd.lib and bnd.lib.util into the m2e.pde feature to avoid the same recent problem of p2 to update sat4j respectively pde to update asm.
This problem becomes worse if we also fetch osgi-bundles directly from Maven-Central. So we should just let P2 do its job.

The only problem is that we do not include all dependencies in the m2e p2-repo.
So we have to list all dependencies of m2e we want to include in the m2e p2-repo explicitly. The good thing is, plug-ins and features are listed without a version in the category.xml so I'm confident this will avoid the mentioned problems.

I will create a separate PR to address those points.

[HannesWell]

Please stop using Require-Bundle for bnd artifacts in m2e.

Done in #652.

[laeubi]

I am concerned about resolution issues when Bndtools and the m2e-pde feature are both installed. This could result in multiple copies of bnd artifacts being installed and resolved.

While using import-package is always preferred I don't see why multiple bnd artifacts should be an issue? One key point of OSGi is its ability to have the same bundle in multiple versions in the same framework and ahndling that case.

If bndtools has restrictions regarding this it should be fixed and do not put the burden to other projects (we recently had this discussion regarding some other project using groovy). Beside that, as m2e only consumes the BND-LIb API and never expose anything from it in its own API I don't see a reason why it should interfere anyways.

[akurtakov]

While using import-package is always preferred I don't see why multiple bnd artifacts should be an issue? One key point of OSGi is its ability to have the same bundle in multiple versions in the same framework and ahndling that case.

The issue I'm aware of is many bundles in the IDE not versioning imports/require-bundles thus open to runtime issues. It is smth that would better be fixed properly but fixing the world happens to be extremely tough job (technically, mentally and socially) thus some extra effort is done to reduce possibilities for extra breakage in order to make one step at a time.

[laeubi]

As mentioned above and you already stated, then these bundle needs to be fixed instead of putting additional cross-project-dependency-management burden on unrelated projects.
Especially for a tool that describes itself as "The easy, powerful, and productive way to develop with OSGi" I assume this should not be an issue...

thus some extra effort is done to reduce possibilities for extra breakage

And that's why nothing changes beside the usual complains ... but I'm sure bnd-tools is well aware of how proper imports work and thus don't expect any issues either with or without this change beside that there might be some not strictly needed extra artifacts around.

[laeubi]

@HannesWell do you think we should include this now? Was there some adjustments in Equinox? How does BND-Tools solve the issue, maybe we can simply use their approach then?

[HannesWell]

@HannesWell do you think we should include this now? Was there some adjustments in Equinox? How does BND-Tools solve the issue, maybe we can simply use their approach then?

Yes I have refactored the corresponding Equinox plug-ins to use the 'original' OSGi bundles from Maven-Central. The Equinox plug-ins that embedded the code will become deprecated for removal. But this will only be available with the Eclipse 2022-06.

If we include this now we would have to add the missing bundles into the m2e repo (and could then remove them again as soon Eclipse 2022-06 is used by m2e).
To avoid this back-and-furth and since this update is not urgent (isn't it?) I suggest we wait one more month until the Eclipse release in about only a month and include this then.

[laeubi]

As I understand m2e 2.x will target 2022-06 so maybe we can just refrence the ibuilds right now?

since this update is not urgent (isn't it?)

Its more that there where some effort to be more compatible with what bndtools uses, so I assume they will use the latest version. From my side, we can wait until the 2022-06 is release without any problem.

[HannesWell]

As I understand m2e 2.x will target 2022-06 so maybe we can just refrence the ibuilds right now?

It is target to be included into 2022-06 but it is released as a standalone project before so if we require Eclipse 2022-06 the new 2.0 release won't be consumable by users until 2022-06 has been released or if one uses the milestone release already.

since this update is not urgent (isn't it?)

Its more that there where some effort to be more compatible with what bndtools uses, so I assume they will use the latest version. From my side, we can wait until the 2022-06 is release without any problem.

Then lets wait for it. :)
Most users come from SimRel but as a service to those that use m2e directly IMHO we should not create a about a month gap where you can't simply upgrade with the latest Eclipse release. If there were a direct need from us or a benefit for the user we could consider it. But without there are more cons.

[bjhargrave]

Then lets wait for it. :)

Well if you wait another week or so, Bnd 6.3.0 will be released :-)

[HannesWell]

/request-license-review

[github-actions]

/request-license-review

All licenses already successfully vetted.

[HannesWell]

Now that we use Eclipse 4.24 in our target-platform we also have the org.osgi.util.promise and org.osgi.util.promise jars from the platform p2-repo available. org.osgi.service.repository is not used in platform so I added it as Maven-dependency.

In order to provide org.osgi.service.repository in m2e's p2-repo I included it in the m2e.pde.feature for now since the bnd.lib dependencies are there as well. Lets use #652 how to handle such cases in the future.