Hi all,
to be honest I'm not familiar enough with mvn to really know how to
debug things, but I'll explain how Gump and mvn play together and toss
out some ideas. Maybe at the end of the thread we will know how to
really debug things. If you can come up with a better idea, I'll be
grateful.
Part of the Gump project is a simple web application that is started
on the same machine that runs Gump. This application is configured as
a proxy to the "central" repository for all mvn projects built by
Gump.
This web application transparently proxies central for all requests it
doesn't know anything about - which is any request at the start of a
Gump run.
When Gump finishs building a jar, it registers the jar with the proxy,
giving a group and artifact id taken from the Gump descriptor.
Subsequent requests to the proxy for any jar (or checksum file) that
matches the combination of groupid and artifactid will return the jar
built by Gump (and matching checksums respectively) - the requested
version is then ignored.
For mvn projects built by Gump this has a few consequences
* only build order matters. A project will get a Gump-built artifact
if it builds after the project that creates the artifact, no matter
whether it explicitly states a dependency on it or not.
* since <option> and <depend> have the same impact on build order, it
is better to only use <option> in the Gump descriptor. If the
dependenciy fails to build in Gump your project can still build and
will get the artifact from central.
* mvn downloads stuff your project doesn't depend on explicitly like
transitive dependencies or dependencies of the plugins you use. It
may be necessary to add those to the Gump descriptor to achieve the
correct build order.
* in general projects share the same local repository (which is
removed after each Gump run). If one project grabs an artifact from
the proxy before the corresponding project has been built by Gump,
this non-Gump artifact will never be replaced by the Gump-built one.
The "Maven Repository Proxy Log" linked from every Gump page needs
to be examined to find such cases.
We have two options here:
(1) add an <option> to the Gump descriptor to ensure the project is
built after its dependencies
(2) for projects where this is impossible (circular dependencies do
exist, unfortunately), throw in separateLocalRepository="true"
on the project's mvn tag. This will give the project a sandbox
to download artifacts to.
OK, I hope I managed to explain it.
Now, how does one debug a situation where the build passes locally
(ehen using the "correct" versions of all dependencies) but fails in
Gump (when using the latest trunk versions of almost all
dependencies)?
In some cases it may be possible to isolate the dependency that causes
the problem: mark your project with separateLocalRepository="true",
remove all dependencies and then add them back one by one (making sure
you add them in the same order they get built by Gump) watching the
Gump runs. Given that a Gump runs every few hours this is a painfully
slow process.
The other option is to run mvn locally and manually overwrite jars in
your local repository with jars built by Gump - which means you'd
either have to run Gump yourself (you don't want to do that), build
your dependencies from trunk yourself or need the jars from the latest
Gump run. Unfortunately we don't make those publically available
anymore (they've been used as nightly builds which is not really a
good idea for oh so many reasons), but it may be possible to make them
accessible to ASF committers more easily - for now the easiest way
probably is to ask on the Gump general list and we'll figure out a
short term solution.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
