Hannes Wellmann created MRESOLVER-572:
-----------------------------------------
Summary: Resolver-Supplier unusable in OSGi runtimes
Key: MRESOLVER-572
URL: https://issues.apache.org/jira/browse/MRESOLVER-572
Project: Maven Resolver
Issue Type: Bug
Components: Resolver
Affects Versions: 1.9.20, 2.0.0-beta-1
Reporter: Hannes Wellmann
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|https://maven.apache.org/resolver/api-compatibility.html#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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
