Add default version of export to selfimports

chrisrueger commented 3 months ago

This is an thought-experiment / prove of concept / based on discussion for #6220. Relates to https://github.com/bndtools/bnd/issues/6220#issuecomment-2302742794

In this PR

after exports and imports have been processed in Builder.analyze()
we calculate self-imports
and then call augmentImports(selfImports, exports) to applyVersionPolicy() to any of those self-imports which a) do not yet have a version or b) specify a range-mask with the rang macro (e.g. Import-Package: example.c;version="${range;[==,=+)}")
-nodefaultversion true still works and could disable the behavior

Based on the observation in https://github.com/bndtools/bnd/issues/6220#issuecomment-2299809530 the following will happen for this bnd:

.bnd:

Bundle-Version: 1.0.1
-exportcontents: example.a, example.b, example.c
Import-Package: example.c;version="${range;[==,=+)}", *

MANIFEST.MF:

Bundle-Version: 1.0.1
Export-Package: example.a;uses:="example.b";version="1.0.1",example.b;version="1.0.1",example.c;version="1.0.1"
Import-Package: example.b;version="[1.0,2)",java.lang,example.c;version="[1.0,1.1)"

instead of as it was before:

Export-Package: example.a;uses:="example.b";version="1.0.1",example.b;version="1.0.1",example.c;version="1.0.1"
Import-Package: example.b,java.lang,example.c;version="${range;[==,=+)}"

Why or When would that be useful?

As outlined in #6220 3rd-party depdencies like Gson etc. use bnd to create OSGi bundles via the maven or gradle plugins. But often there is no OSGi-knowledge present hence there are often no version information at the package-level like:

packageinfo file in the package directory (recommended)
package-info.java, bnd’s Version annotation
Manifest of the exporting JAR

Only a Bundle-Version is usually mainted.

For all those dependencies out there the previous behavior already added the Bundle-Version as the last resort to Exports, while self-imports would not get any version information.

But now the self-imports would get the version information from the export even it is the "last resort" Bundle-Version

Open Questions

what about if this be the (new) default behavior?
does it even make sense?
what could go wrong if this would be the new default? What could it break?
or should there be a new option / instruction to enable this behavior?

Feedback appreciated @pkriens @bjhargrave

bjhargrave commented 3 months ago

This is a bad idea. Because export defaults to using Bundle-Version does not mean it is a valid choice on the import side. There is probably no other bundle which exports the package at the Bundle-Version of the importer. So matching the import at the Bundle-Version will be pointless. Bundle-Version is not semantic and thus not suitable for use on imports.

Exporters need to use proper versions. Importing at the Bundle-Version is a bad idea. So I would reject this proposed change.

chrisrueger commented 3 months ago

Thanks @bjhargrave for the feedback.

I am just wondering if there is any other way out of the situation described in https://github.com/eclipse-jdtls/eclipse.jdt.ls/issues/3236#issuecomment-2276399714 other than manually fixing in upstream (gson).

The problem, as you've noted, is that both gson bundles import just "com.google.gson.annotations" (implied >= 0.0.0) leaving the door open for resolution between different versions of the same library 😐 gson 2.10.1 should import with a range of [2.10.1,2.11.0) and gson 2.11.0 should import with a range of [2.11.0,2.12.0) to be safe.

com.google.gson_2.10.1.jar Import-Package = sun.misc;resolution:=optional,com.google.gson.annotations;version="[2.10.1,2.11.0)"

com.google.gson_2.11.0.jar Import-Package = sun.misc;resolution:=optional,com.google.gson.annotations;version="[2.11.0,2.12.0)"

My interpretation is that gson "expects" that its own com.google.gson.annotations is imported, but apparently another bundle of the same library got wired.

bjhargrave commented 3 months ago

The solution is always to fix the upstream :-)

In the alternate, if the bundle must not import the package from another bundle, then its bnd instructions should decorate the export with -noimport:=true. Then it won't self-import and will just export. When the bundle goes to access the package, it will always use its own copy since it can never import the package.

chrisrueger commented 3 months ago

Closing. Continue at comment https://github.com/bndtools/bnd/issues/6220#issuecomment-2312660794

chrisrueger commented 1 month ago

@juergen-albert @maho7791 ocx conference car discussion

bndtools / bnd