It turned out to require not too much Python knowledge to make Gump support building with make - and have it support all the stuff needed to build C projects against each other.
As a proof, we are now building APR and Apache HTTPd in Gump - of course HTTPd gets built against the latest versions of apr and apr-util.
Next up should be building .NET projects. There already is a NAnt builder, but at the moment Mono is giving us trouble on our Debian box.
path: /en/Apache/Gump | #
Apache Gump is the ASF's large scale integration project which currently builds a whole bunch of Open Source Java projects from source over and over again.
Apart from its regular runs performed on JDK 1.4 we also have experimental runs on Kaffe (more on that sometime later) and JDK 1.5. The results can be seen here. In short, they are a desaster since almost no project builds without special tweaks to either code or the build files.
Here are the most common traps:
Backwards incompatible API changes
Our all time favorite, isn't it? This time it is not JDBC but JAXP that is causing the biggest problems. org.w3c.dom.Node and javax.xml.parsers.DocumentBuilderFactory have changed, for example.
We had to drop Xerces-J 1 and Crimson from our Gump portfolio since nobody is going to adapt them. But not only parsers are affected, it will be interesting to see how things like Cocoon or dom4j will work out, once we manage to build the projects they depend on.
This means neither Xerces-J 1.x nor Crimson can be compiled or used with JDK 1.5. Sometimes software does go bad.
-
I'm not sure whether this is a bug in javac or the default has changed silently or what has happened. javac will now choke on non-ASCII characters even if the source files use the platform's default encoding. This causes problems with @author tags of international contributors and similar comment contents.
The solution is to either use unicode escape sequences or explicitly specify the encoding attribute of your <javac> task (you can't rely on the defaults any longer).
-
Actually it already changed with JDK 1.4. Prior to JDK 1.4 it defaulted to
1.1while JDK 1.4 changed it to1.2. So generated classes became incompatible with JDK 1.1 and many project started to explicity specify target="1.1" in their build files. Others didn't since they didn't plan to support JDK 1.1 anyway. With JDK 1.5 the new default is1.5, this means generated code can only run on JDK 1.5, which most likely is not what you want.The solution for cross-JDK build compatibility is to explicitly specify the target attribute.
-
In JDK 1.4 the default was
1.3, in JDK 1.5 it is1.5.This leads to a few kinds of problems:
- Your
Enumeration enum = ...is no longer going to compile. - Combined with the new default value for
-target, if you have specified-target 1.1but no-sourceyou will now getjavac: target release 1.1 conflicts with default source release 1.5
The solution for cross-JDK build compatibility is to explicitly specify the source attribute. To add to the pain, JDK 1.4.0 and 1.4.1 will not accept
1.1or1.2as values for the source attribute. - Your
-
Ant's <junitreport> went through this and it took us until Ant 1.6.2 to finally make it work.
JDK 1.5 comes with Xalan XSLTC instead of Xalan-J 2.x as processor. This has a few consequences:
- If you rely on Xalan extensions in your stylesheets they may no longer work. Some of them can still be used with XSLTC but if you used the "old" namespaces identifiers like "org.apache.xalan.lib.Redirect" you'll have to switch. See the XSLTC site for help and details.
- If you have Apache's
xml-apis.jaron your bootclasspath or use it via the "endorsed standards override mechanism", you'll probably have to put Xalan-J there as well since this jar defaults to Xalan-J as its TraX processor - which is no longer there. - XSLTC is an incredible memory hog. You'll probably want to use the endorsed standards override mechanism and use Xalan-J 2.6 (or Saxon) anyway.
path: /en/Apache/Gump | #
Somebody has to mention it, so why not me. Gump has been promoted to a stand alone project in Apache land and is no longer a sub-project of Jakarta. This is another step to show that Gump isn't all about Java, or at least it shouldn't be.
Gump started as an integration project for some Apache code bases, building projects every night from CVS and compiling each project against the latest version of the projects it depends upon - instead of a released version. It has since then by far outgrown its initial purpose and is in use to communicate code changes between 484 projects in 181 modules (being CVS or Subversion modules) right now - actually Gump's purpose is now to get the developers of those projects to communicate with each other.
Right now it can only build projects that either use a shell-script/batch-file combo or Ant, Maven support is on the way.
It's still very much Java centric, something we really want to address. We (well, most of the work is done by Adam) are currently rewriting Gump in Python. If you are interested in helping out, or want to help us reach into non-Java projects, you are more than welcome. Please join us at generalATgump.apache.org.
path: /en/Apache/Gump | #
A while ago I added XOM to Gump because Jaxen needed it. This weekend Elliotte Rusty Harold asked us to send nag mails if XOM fails to build. I consider this a small success story for Gump.
Maybe I should submit it to the Gump group blog provided by Nick Chalko.
path: /en/Apache/Gump | #
Thanks to the Python coding by Adam Jack and infrastructure provided by Leo Simons and Scott Sanders, Gump is not only building stuff at night but also telling people that their projects fail to build.
First results are visible, Craig wants to have his name removed from the nag mails and some members of the Mockobjects team want us to stop telling them that their code doesn't compile ;-)
More seriously, Scott has made Jaxen compile in Gump and brought us a big step forward, Mockobjects has been built successfully last night and Bill Barker is working on getting Tomcat built again - so there are visible improvements already.
path: /en/Apache/Gump | #