The Apache Gump project is five years old today and its birthday present is support for git.
To be honest I started working on git support when I saw JUnit moving away from Sourceforge a few weeks ago - and I didn't realize Gump's birthday was upcoming until last week. Still it is a nice coincidence and made a good tag line.
The Python code to use git has been in trunk for a a few days and I merged it into the code base running main Gump yesterday. Of course I managed to break the four lines of Python code I didn't run via Pylint, twice. Sorry for the broken Gump runs last night.
Norman Maurer helped me out when I had trouble getting git installed on the Solaris Zone (one of many people I owe a beer in Amsterdam) and I hope I now have a working version of git on vmgump. When all things look good I'll turn the switch on JUnit.
Next up will be darcs, Mercurial and Bazaar - but since we don't really have any project using them, it is a rather low priority project to me.
path: /en/Apache/Gump | #
I've finally merged the experimental code that tries to make Gump useful for mvn (this is Maven 2.x 8-) built projects from trunk to live. This means that vmgump will be using it and I'd expect a few hickups.
While things worked fine on the Solaris zone this instance has only been building a handful of projects since excalibur-logkit won't build on Java6 and thus brings down the success rate to less than 40%. vmgump will be different.
Basically Gump will now put a proxy (a Restlet based web application) between mvn and the repository and inject its own jars whenever possible. More on this later.
More details on the Gump descriptor side of things can be found here (once the site has been synced, that is).
path: /en/Apache/Gump | #
Disclaimer: this is not a "real" Gump build, we are cheating. Still: http://vmgump.apache.org/gump/public/jakarta-bcel/bcel/gump_work/build_jakarta-bcel_bcel.html.
What we do right now is we simply let Maven2 do what it wants to, i.e. it will download stuff and it will be allowed to build against whatever it has pulled down. This is why it is not a "real" Gump build, it really just is a nightly build that doesn't integrate with anything.
The reason it has been enabled that way is that we are now at least able to build projects like BCEL. BCEL doesn't get integrated with the latest regexp, but at least those projects that depend on BCEL can build against the latest code instead of a packaged version. So while we don't provide continuous integration for Maven2 builds now, we provide it for projects that happen to depend on such projects.
I plan to enable it gradually for projects that other (Maven1 or Ant built) projects depend on, while I don't intend to add Maven2 builds for leaf projects. Nightly builds for them can be provided in a better way outside of Gump IMHO.
This doesn't mean we've given up on doing full integration builds with Maven2, it is simply taking longer than is healthy for the Gump project tree as a whole.
path: /en/Apache/Gump | #
After somebody tried to break into my server using one of the more recent security leaks in a Linux installation I thought it would be time to update vmgump.apache.org as well. I've done remote system updates with and without reboots at least a hundred times both at work as well as with my own servers. I never had any problems, but I always knew whom to call if anything bad should happen.
This time I didn't have a phone number and driving to the colo wasn't an option either. I had this "will this go well?" feeling when I typed "shutdown -r now" but still proceeded. Guess what, the machine hasn't come back to live yet.
I've broken Gump builds by breaking the Ant bootstrap process before, but at least I could fix it myself. This time I can only wait for somebody with proper karma to help out. I guess I'll stay away from sysadmin stuff in the future.
path: /en/Apache/Gump | #
A while back I promised to talk about Gump running on Kaffe.
Dims and a few of us Apache Gump people work together with Dalibor and a few other Kaffe people and try to build as much as possible on the Kaffe VM.
The problems we've solved so far
- Kopi KJC simply doesn't work for many builds
KJC is not greedy, this means it will only compile the files you tell it to compile. This is different from the JDK's javac which will also include referenced classes in the compilation if it can find them on the -sourcepath.
The first thing that failed was Ant's bootstrap script, which in turn was too cumbersome to fix - so we decided to use jikes as our Java compiler.
- GNU JAXP already implements JAXP 1.3, including DOM3
This issue is the same as building on JDK 1.5, many sources need to be changed if they want to compile with DOM3. We simply move the JAXP 1.2 stack into Kaffe's bootclasspath just like we do for JDK 1.5.
- Kaffe's class library is incomplete
and who would have thought that missing Swing methods make the JUnit compilation fail? The Kaffe/Classpath developers have been extremely busy and right now I'm not aware of any build that failed because of missing classes/signatures.
- Builds relying on com.sun.* or sun.* classes
Things that use the Base64 codec or other "undocumented secret classes" will fail when they compile or run on Kaffe. There isn't much anybody could do, except for rewriting the Sun classes or wrapping them behind reflection.
- rmic
At first Ant didn't support Kaffe's rmic (it only supports an older version in 1.6.2). This has now been fixed, but Kaffe's rmic itself doesn't work as expected. Dalibor is working on it.
- Ant doesn't support some other JDK tool alternatives coming with Kaffe
At least <native2ascii> and <javah> should now work - in CVS HEAD as well as Ant 1.6.3.
So far it has been a lot of fun to see the number of projects we managed to build in Gump increase with every hurdle we jump over. Every now and then Kaffe is broken, or I break Ant's bootstrap process for Kaffe. But the general direction is very positive. On good days we've been able to build ~25% of all projects Gump wants to build - on JDK 1.4 we manage to build ~85% of them, on JDK 1.5 ~60%.
path: /en/Apache/Gump | #