gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject mvn builder status update
Date Mon, 04 Feb 2008 11:13:52 GMT
Hi all,

during the past weeks I've spent the little time I had available
fighting against processes that don't want to go away on helios.

Whenever the Gump run dies - which seems to happen more frequently on
helios than I would have thought - the mvnrepo Java process doesn't
get terminated.  This is because I stop it during the FinalizeRunEvent
which is never triggered.  I'm uncertain of whether any other approach
- like a post_run script - would work better, I don't think it will.

What is even more surprising to me is that even an explicit
System.exit doesn't terminate the Java process once it has lost its
Python parent.  My next attempt would be to completely redirect all
streams of the Java process, but that may take some time.

Rather than waiting for this to be perfect I'd like to go ahead and
merge what we have in trunk to the live branch now - after I have at
least roughly documented what is there:

* there is a new Java application that acts as a proxy for mvn's
  repository access

* whenever Gump has successfully built a project it notifies the proxy
  about the jar(s) together with what Gump thinks are the group- and
  artifactIds of these jars

* when asked for a known groupId/artifactId combination, the proxy
  will hand out the Gump-built jar and matching SHA1 and MD5 checksums

* when asked for anything it doesn't know - this includes POMs - the
  proxy defers to repo1.maven.org

* right now the groupId is the module's name, but I intend to make
  that configurable before I merge the stuff.

* the artifactId is the id attribute of the <jar> element if any, the
  name otherwise

* each <mvn> builder can state that it wants a local repository of its
  own.  This is for cases where we need to build projects against
  released instead of Gump-built artifacts in order to break cyclic
  dependencies.  A separate local repository ensures that we don't
  "polute" mvn's local repository wih artifacts that haven't been
  built by Gump.

* mvn built projects don't need to specify their dependencies for
  anything but making sure the build order is correct.

Stefan

-- 
http://stefan.samaflost.de/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message