river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Wright <pdoubl...@gmail.com>
Subject Re: Maven repository Entry was Re: Codebase service?
Date Tue, 25 May 2010 12:42:03 GMT
> 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 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.

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


Patrick

Mime
View raw message