Details
Major Description
The maven-resolver-supplier artifact cannot be used as bundle in an OSGi runtime because it uses and therefore imports internal packages from maven-resolver-impl. But those internal packages are not exported by maven-resolver-impl and therefore maven-resolver-supplier fails to resolve.
In order to fix that I see two possible solutions:
- Export (almost) all internal.impl packages from maven-resolver-impl.
This would be the simpler solution (probably a one/two-liner in the bnd-maven-plugin config) but it means that at runtime those internal packages would be accessible.
For Eclipse (PDE) there is the convention to mark 'internal' packages with the directive ;x-internal:=true, that this emits a warning at callers in the IDE but does not prohibit access. At runtime there is no in-between, either a package is exported or not.
According to the doc at package-level-contracts all packages in maven-resolver-impl are considered 'non-API' anyways regardless of if the only contain impl or internal.impl. Furthermore one is not prohibited to use elements from internal packages, but only cannot expect any compatibility between versions. So just exporting it, with a warning at callers (if x-internal is considered), sounds like a not too bad solution. And it would be similar to non OSGi situations where one can access everything available. - Split the supplier into two, an abstract BasicSupplier that contains all code that touches the internal.impl elements and the already existing supplier that extends the BasicSupplier and adds everything that's not available in resolver-impl, like elements from higher-level resolver modules or maven-core/model.
For maven-resolver 1.9.20 I have checked it already and it would be possible. The BasicSupplier would only have to reside in an exported package.
I haven't checked resolver 2.0 yet, but such BasicSupplier could also help to reduce the duplication's between the suppler for Maven 3 and 4.
A BasicSupplier could also help third-party suppliers to reduce the depencency footprint without re-implementing everything if they have alternate means to the maven-core/model elements.
What's the solution you prefer?
Maybe approach two would only be suitable for resolver 2.0.x in order to also reduce code and for 1.9x. only approach one would be sufficient? Approach one would probably also be suitable for 2.0.x since it gives consumers the possible to access internals if they really want to.