maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Lipp <...@mnl.de>
Subject Re: Accessing a maven repository programatically (in 2019)
Date Sat, 20 Apr 2019 20:43:55 GMT
On 2019/04/08 11:21:19, Paul Hammant <p...@hammant.org> wrote:
> There's shades of https://en.wikipedia.org/wiki/XY_problem to what you>
> posting. I, for one, an interested in what your trying to make after
you've>
> solved this problem :)>

It's not trivial. There is a tool called "bnd" that supports the
development and deployment of OSGi bundles. The tool works "natively"
with OSGi Repositories
(https://osgi.org/javadoc/osgi.cmpn/7.0.0/org/osgi/service/repository/Repository.html).
There are various bnd plugins that provide "OSGi repository views" on a
selection of artifacts from one or more maven repositories. In order to
do this, bnd provides its own library for accessing maven repositories,
including classes for parsing and evaluating POMs.

When I started to write my own bnd plugin
(https://github.com/mnlipp/de.mnl.osgi/tree/master/de.mnl.osgi.bnd.repository)
I found that bnd's POM evaluation lacks some features. My first idea was
to replace all of bnd's maven library with the "standard" maven library.
This led to my initial question in this list. Sorry to say, but none of
the answers really helped. I dug further through the maven API and the
sources. Much too late I found
https://lairdnelson.wordpress.com/2017/03/06/maven-and-the-project-formerly-known-as-aether/,
I wish I had found it earlier, would have saved me a lot of "digging".
It is obviously impossible to use the "standard" maven library (or
better "components") without a ridiculous number of (partially
redundant) CDI libraries. (That gave me quite a different perspective on
bnd's sleek implementation.)

Having understood this, I thought about fixing the problems I had
identified with bnd's POM handling. But somehow, it seemed ridiculous to
maintain this non-trivial functionality twice. So what I have ended up
with is this:
https://github.com/mnlipp/de.mnl.osgi/blob/2e9246a3a1fe416c50ec3667676a95b92babe232/de.mnl.osgi.bnd.repository/src/de/mnl/osgi/bnd/maven/CompositeMavenRepository.java#L134
. I use the "components" from the maven library and assemble them myself
to avoid pulling in all those CDI libraries. Assembling the components,
I found that eventually the only "repository functionality" required to
evaluate a POM into a "Model" (using the standard maven components) is
an implementation of "ModelResolver". I therefore provide such an
implementation based on bnd's repository (access) classes
(https://github.com/mnlipp/de.mnl.osgi/blob/bnd.repository-2.0.0/de.mnl.osgi.bnd.repository/src/de/mnl/osgi/bnd/maven/BndModelResolver.java).
Maybe I'll some day try to assemble a "standard" repository access from
the (former) aether components. But actually, this part of bnd's maven
library seems to work flawlessly, so my motivation is quite low. (And I
still don't understand the aether API. It seems to duplicate a lot of
the functionality provided by the org.apache.maven.* classes.)

Is this an X/Y problem? Maybe. The question was "How can I use the maven
libraries for (easily) accessing a maven repository?". Maybe I should
have asked first "Is the collection of maven APIs in the various
libraries intended to support easy access to the content of a maven
repository?"

 - Michael



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message