This repo: https://github.com/airlift/resolver should have all you need. The Presto engine uses it to discover and load plugins if necessary from the local or remote repo. It uses the sonatype version of Aether, not the current Apache Maven Artifact Resolver but my guess is that this is straightforward to refactor.
-h On Sat, Apr 20, 2019 at 10:16 PM Michael Lipp <[email protected]> wrote: > On 2019/04/08 11:21:19, Paul Hammant <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
