Hi all, since Leo caught my last commit, I think it is time to shed some light on the current state.
The mvnrepo Java code I've committed works the way I'd like it to work, mostly. If I tell mvn to use a running instance of it as a "mirrorOf" central it will act as a transparent proxy to repo1.maven.org. If I add jars for a given combination of groupId and artifactId to a running instance it will hand out this jar (and calculate SHA1 and MD5 checksums on the fly when asked) instead of talking to a real repository. This approach to "the Maven2 problem" means, Gump doesn't need to know which concrete versions a mvn build is going to ask for, it will always return the Gump built one, no matter which version is requested. It also means Gump doesn't have to provide POMs on the fly since they are proxied. As long as I set up the mvnrepo application manually it works really fine. The things that are missing: * start it when Gump starts * use a different port number for different Gump runs (so test and Kaffe can be running simultatniously on helios) * dynamically add the jars for projects once they have been built * download /proxyLog.html and store it with the other logs * stop it when Gump is done * dealing with repos other than "central" So why have I changed trunk in a way that gives each Maven2 project a fresh local repository? There are a bunch of jars that Maven requires to even start, those will be downloaded on the first run. We won't be able to provide them upfront until we manage to bootstrap Maven2 (read: never), so we must allow the builds to download them. Among those jars is JUnit 3.8.1. So unless the project states a dependency on JUnit (and thus comes after JUnit in build order) JUnit 3.8.1 will end up in the local repository and any build asking for that version is not going to be using Gump's jar. Maybe JUnit is the only such jar, in that case making all mvn builds depend on JUnit might be the better option. I'm just not sure that no other things like (say) velocity or dom4j end up in the local repo the same way. Even if we didn't use a different local repo for each build, we will need one for each Gump run (and throw it away at the end) in order to get the latest jars. Oh, and Maven currently doesn't like it when separate mvn instances write to the local repo at the same time, which might prevent us from running several builds in parallel unless whe hand out different repos to each build. It is not very likely that we are going to run a multi-process Gump anytime soon, though. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
