[
https://issues.apache.org/jira/browse/MRESOLVER-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-572:
--------------------------------------
Affects Version/s: 2.0.0-alpha-11
(was: 2.0.0-beta-1)
> 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: 2.0.0-alpha-11, 1.9.20
> Reporter: Hannes Wellmann
> Assignee: Guillaume Nodet
> Priority: Major
> Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1
>
>
> 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)
