gump-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r627104 - in /gump/trunk/src/documentation/content/xdocs: index.xml metadata/builder.xml
Date Tue, 12 Feb 2008 21:04:14 GMT
Author: bodewig
Date: Tue Feb 12 13:04:11 2008
New Revision: 627104

document how I think mvn builds work now


Modified: gump/trunk/src/documentation/content/xdocs/index.xml
--- gump/trunk/src/documentation/content/xdocs/index.xml (original)
+++ gump/trunk/src/documentation/content/xdocs/index.xml Tue Feb 12 13:04:11 2008
@@ -34,7 +34,7 @@
 Gump is Apache's continuous integration tool. It is written in python and fully supports
Apache Ant, 
-Apache Maven and other build tools. Gump is unique in that it builds and compiles software
+Apache Maven (1.x and 2.x) and other build tools. Gump is unique in that it builds and compiles
software against 
 the latest development versions of those projects. This allows gump to detect potentially

 incompatible changes to that software just a few hours after those changes are checked into
 version control system. Notifications are sent to the project team as soon as such a change
@@ -43,7 +43,7 @@
 You can set up and run Gump on your own machine and run it on your own projects, however
it is 
-currently most famous for building most of Apache's java-based projects and their dependencies
+currently most famous for building most of Apache's Java-based projects and their dependencies
 constitutes several million lines of code split up into hundreds of projects). For this purpose,
 gump project maintains its own dedicated server.
@@ -53,9 +53,8 @@
   <section><title>How does Gump work?</title>
-      With Traditional Gump, <link href="">
-      project</link> definitions are converted from XML to scripts native to the
-      platform on which you are running.  With Python Gump the XML is mapped into in memory
+      With Gump, <link href="">
+      project</link> definitions are mapped from XML into in memory
       objects for processing. Scripts execute cvs or svn update
       commands for every module which contains a project being built, and
       invoke builds for each project in an order that ensures that dependencies
@@ -64,17 +63,50 @@
-      The commands use the actual build.xml files from the projects, but do
-      not use the scripts or jar files checked into CVS/SVN.  Instead, the
-      CLASSPATH is set and properties are passed on the command line.
+      The commands use the actual build.xml/Makefile/pom.xml files from the projects, but
+      not use the scripts or jar files checked into CVS/SVN.  Instead,
+      Gump tries to play several tricks in order to ensure that Gump's
+      versions of files are used.
-    <note>
+    <p>
+      In order to really build against the latest versions of
+      everything, Gump will need support from the build process, the
+      build tool or has to find its way around the build tool.
+    </p>
+    <p>
+      The <fork
+      href="">HTTPd
+      builds</fork> are an example for a build process that supports
+      Gump.  HTTPd needs APR and Gump can provide the path to the
+      freshly built APR files as command line options to the buildconf
+      and/or configure scripts.
+    </p>
+    <p>
+      In Ant's case
     	Gump set's Ant's <link href="">build.sysclasspath</link>
to <strong>only</strong> and manages the system classpath:<br/>
     	To quote Ant:<br/>
     	<em>Only the system classpath is used and classpaths specified in build files,
etc are ignored. 
-    		This situation could be considered as the person running the build file knows more
about the environment than the person writing the build file</em>
-    </note>
+    		This situation could be considered as the person running the build file knows more
about the environment than the person writing the build file</em>.<br/>
+      Note that Gump uses the svn trunk version of Ant when building Ant projects.
+    </p>
+    <p>
+      For Maven 1.x builds, Gump runs maven with the --offline switch
+      and uses jar overrides.  Sometimes the artifact ids expected by
+      maven and Gump's names of the jars don't match, in which case
+      &lt;property&gt; elements have to be used to get the correct
+      artifact ids.
+    </p>
+    <p>
+      So far Gump's support for Maven 2.x uses the most complex
+      approach, for the full story see <link
+      href="metadata/builder.html#mvn">the section on the mvn
+      builder</link>.
+    </p>
       The net effect is that every project is built every day with the latest
@@ -90,10 +122,8 @@
-      A Perl script which is driven off of a naglist will optionally send
-      e-mails to various newsgroups upon matching strings being found in the
-      build output.  This is typically used to alert developers of build
-      failures.
+      The "official" Gump run on vmgump will optionally send
+      e-mails to various newsgroups upon build failures.
@@ -122,8 +152,13 @@
         <td><fork href="">Apache (vmgump)</fork>
-        <td>1.4.2_04</td>
-        <td>4 times daily</td>
+        <td>1.5</td>
+        <td>up to 3 times daily</td>
+      </tr>
+      <tr>
+        <td><fork href="">Apache (helios)</fork>
+        <td>1.6</td>
+        <td>up to 4 times daily</td>

Modified: gump/trunk/src/documentation/content/xdocs/metadata/builder.xml
--- gump/trunk/src/documentation/content/xdocs/metadata/builder.xml (original)
+++ gump/trunk/src/documentation/content/xdocs/metadata/builder.xml Tue Feb 12 13:04:11 2008
@@ -360,25 +360,57 @@
     href="">Maven 2.x</fork>, it does
     <strong>NOT</strong> bootstrap Maven from svn trunk, yet.</p>
-    <p>Gump generates a <strong>settings.xml</strong> that points mvn
-    to a proxy application disguising as a mirror of the central
-    repository.  If mvn tries to download an artifact that has been
-    built by Gump already, the proxy is going to return Gump's version
-    - otherwise it retrieves the artifact from the central
-    repository.</p>
+    <p>
+      First of all, all mvn built projects use the same local
+      repository for artifacts they've downloaded and this local
+      repository is wiped out after each Gump run.  This can be
+      overriden on a per build basis, see below.
+    </p>
+    <p>
+      When Gump starts up, it starts a web application on the build
+      server that acts as a proxy for mvn repository requests.
+      Whenever a project has been built successfully Gump registers
+      the created artifacts with this proxy.  When the proxy is asked
+      for a jar artifact and a jar with matching group and artifact id
+      has been registered, the proxy will completely ignore the
+      specified version and serve the Gump built jar file - and
+      calculate SHA1 as well as MD5 checksums for them on the fly as
+      needed.  Any other request that is unknown to the proxy will be
+      passed on to the central mvn repository, in particular the proxy
+      will never serve POMs itself.
+    </p>  
+    <p>
+      Technically it is not necessary to declare the dependencies of a
+      mvn built project since artifacts will be retrieved from the
+      proxy even if Gump doesn't know about the dependency.  This can
+      only work if the dependency has already been built, though, so
+      it is still better to list all dependencies inside the Gump
+      descriptor in order to maintain correct build order.
+    </p>
+    <p>
+      Maven 2.x and some of its plugins will also download jars even if
+      the project itself doesn't need them.  It is a good practice to
+      watch the log file of the repository proxy and add the jars that
+      have been obtained from the central repository as explicit
+      dependencies to the projects that have asked for them.
+    </p>
+    <p>
+      Sometimes a project simply cannot depend on another project
+      built by Gump since it would cause a dependency cycle.  One such
+      example is BCEL, which is needed by Xalan and thus transitively
+      by a lot of other projects.  BCEL is built using Maven 2.x and
+      uses a plugin that depends on JMock and commons-lang, both of
+      which transitively depend on BCEL.  The way around this is to
+      allow BCEL to obtain those jars from the central repository (by
+      being built first) but make it use a separate local repository
+      so that subsequent requests for JMock and commons-lang by other
+      projects will use Gump's versions instead of the released ones.
+    </p>
-    <p>Gump generates a <strong></strong> file for
-    Maven, in which it specifies the jar <link
-    href="">overrides</link>,
-    and also any <link href="project.html#property">properties</link>
-    that are passes into the &lt;maven&gt; element.</p>
-    <p>Gump does <strong>not</strong> read the Maven pom.xml (POM) to
-    attempt to determine dependencies, the Gump descriptor needs to
-    have them mostly to ensure build order is correct.  If a
-    dependency has been built by Gump, the repository proxy is going
-    to provide it even if Gump doesn't know about the dependency.</p>

View raw message