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
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
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
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.
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]