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. >
