> 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
