river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Maven repository Entry was Re: Codebase service?
Date Tue, 25 May 2010 13:01:46 GMT

On May 25, 2010, at 842AM, Patrick Wright wrote:

>> Okay, I agree with you here. This also means the we dont need to refactor MarshalledInstance
right? If not then we may need another entry type, one for non-maven artifacts as well.
> I have no opinion (and almost no knowledge) of MarshalledInstance...
>> Also lets remember that for maven resolution, I think you'll also want to either
provide support for parsing your maven settings.xml or include the repositories to go find
the artifact if it's not present. If we dont do this then we need to include some wiring to
include the repository location(s) that the primary artifact can be resolved from in the entry
as well.
> What I was imagining is that in the client configuration, one would
> provide the class which could handle these special entry types. That
> class (for Maven) would most likely use the home/local repository by
> default, and an extended version could use some or all of the maven
> embedder to handle more complex (and transitive) lookup in other
> archives.

I think its absolutely key to provide support for the resolution of transitive dependencies
out of the gate. The resolution of a maven artifact needs to do 2 things:

1. If necessary download the artifact and it's dependencies (transitive included)
2. Produce a classpath from the resolved artifact(s) 

> I haven't actually used these APIs in Maven but my
> understanding is that they are exposed and can be used. Sorry if I
> can't be more specific. I have an idea of how this could work but
> don't have a grasp of the plumbing involved.

I went through the investigation of embedding maven for this use and ended up writing my own
resolver for the following reasons:

• For starters, we want to abstract the underlying dependency resolution implementation
in order to give the flexibility to potentially support other repository based dependency
management approaches. 
In the future we may seek to provide support for Ivy or the OSGi Bundle Repository. Providing
an abstraction on top of the concrete dependency management solutions gives us flexibility
going forward. The resolver itself is configurable. The resolver provider can be specified
by providing a resource named "META-INF/services/org.rioproject.resolver.Resolver" containing
the name of the provider class. If multiple resources with that name are available, then the
one used will be the first one returned by ServiceLoader.load. A similar approach can be used
for River I would think.

• Secondly, the ability to embed a Maven resolver into the Rio runtime was initially tried,
but we found that the Maven Embedder would not be supported until the 3.0 betas. As of this
release Maven 3.0 is still at alpha. So in an effort to be in control of our own destiny,
a Resolver that interacts with Maven2 repositories was created.

(more here http://www.rio-project.org/resolver.html)

> What does concern me a little is the impact on the time required to
> load a service if it needs to download JAR files from remote
> repositories. This is especially an issue with 3rd party libraries
> included via transitive dependencies. I don't have a solution, but
> it's probably something we need to warn people about.

Yep. BTW, this is why we recommend the use of repository managers. It really takes the pain
out of resolving transitive dependencies. Key to this is also making sure settings.xml is
set up, and/or you have access to the artifact's pom.xml

> On the other
> hand, there are two good competition repository hosts for Maven so
> it's not that much of a problem for people to set this up.

View raw message