Even though I can't remember who said it I've heard several times that Germany had one of the best railway systems of the world. Poor rest of the world.
Monday morning I entered the train scheduled to leave for Venlo at 7:25 in time and started to read my newspaper when there was an announcement that some other train had broken down and was blocking the rails and our train wouldn't be able to go - it probably was to be cancelled but we should wait for more announcements to be made. Stepped outside, looked at the board and it said: delayed by approx. 25 minutes. It still said the same thing an hour later without any further information provided by the Deutsche Bahn. Then they announced the next scheduled train to Venlo (8:25) would be leaving from a different platform - obviously, my train was at the planned platform. I decided to take the other train and for some reason that one wasn't blocked by any other train. I reached Venlo, changed to a train going to Eindhoven, changed to a train to Amsterdam and arrived just an hour too late.
Since I also had to change trains twice on my way back I was a bit afraid the same thing might happen again, in particular since the train leaving Venlo at about 10pm was the last one to reach Germany for the day. My train left Amsterdam in time, was a bit late in Eindhoven but the connecting train waited for us and I even left Venlo in time. Soon after I reached Germany the train came to a full stop and we were told there was a train broken down and blocking the rails. Deja Vu. Fortunately it took them only thirty minutes to resolve that and I reached home at half past eleven.
Deutsche Bahn vs Dutch Railway 0:2.
Between those train rides the Hackathon was really successful, I met a few people I didn't know before and had a really good time. I even found out there was a route of bridges crossing the big channel between the Mövenpick and the hotel I stayed in that I didn't know, this route cut my time walking from my hotel to the Hackathon in half - ten instead of twenty minutes.
Let's see how my plans worked out:
- EasyAnt: Reviewed it and asked a bunch of questions. It really looks as if it might allow some simplification for certain cases and the changes required to Ant's core will generally be useful for other builds.
- AntUnit: implemented three enhancement requests, one of the remaining open issues looks like an Ant core problem.
- (Re-)Adding Cocoon, Felix and Jackrabbit to Gump: Carsten Ziegeler was my victim of choice for support requests - as well as for the next two points. I'm going to tackle the projects one after the other and started with Cocoon but unfortunately it doesn't build as a reactor build. At first we (me, Carsten and Reinhard Pötz) hoped switching from Maven 2.0.6 to 2.0.8 would help, but we still have Maven complain about a missing artifact that it is supposed to build during that same reactor build (that's my reading of the error). I fully plan to stay on this and get Cocoon working, after all Cocoon was Sam's reason to start Gump in the first place.
- Learn more about OSGi and how Ant could support it: No concrete results (yes, I learned more) but some ideas.
- Getting Logkit compiled using Java6: turned out to be impossible without breaking Java 1.3 compatibility at the same time. JDBC 4.0 added some generic methods to the DataSource interface so you cannot compile an adapted class prior to Java5 - and Excalibur targets 1.3. Turned avalon-logkit into an "installed package" and we now build far more projects on the Solaris zone - and see more interesting breakages like tests for excalibur-pool-impl or commons-io hanging for an hour and being terminated by Gump after that.
As usual there was some more Gump activity during the Hackathon. Petar Tahchiev re-added Cactus and we first ran into a problem with Cactus requiring JUnit3 while the Maven2 proxy would provide JUnit4. When switching to JUnit3 we see a Maven2 error message I don't understand. Is this Maven complaining that the surefire-plugin downloaded from central was broken in some way?
Niall Pemberton fixed a Solaris issue with commons-io that was showing up on our Solaris zone and also fixed a race condition in the commons-collections testsuite that was breaking tests on the zone - I don't know whether it was the speed of the zone, Java6 or the concrete Java VM for Solaris that uncovered it. Right now we see several failures on the Solaris zone (like the hanging tests) that look as if they had been caused by a different thread scheduling policy from what was expected.
Thomas Vandahl helped me re-discover village which now is a part of Torque, I hope the next build of it is going to be successful (needed to manually add some plugins to the local Maven1 repository).
Henning Schmiedehausen had a quick look at some Velocity test failures in Gump which are most probably CLASSPATH related. It doesn't work, yet, but I do know a few things to try next.
path: /en/Apache/ApacheCon | #
This year I'll only attend the Hackathon at ApacheCon EU, which means I'll arrive Monday morning and leave early Tuesday evening. Besides the usual "meet folks and put faces to email addresses" aspect I really intend to spend some time coding this year, in particular I want to
- take a serious look at Xavier Hanin's EasyAnt ideas.
- work on some AntUnit issues.
- talk to some Cocoon, Felix and Jackrabbit folks about (re-)adding the projects to Gump now that we can do Maven2 projects.
- find somebody who can tell me more about OSGi than I currently know. I have this nagging feeling that it would be a good idea to support it in Ant on various levels.
- talk to some Excalibur folks (if there are any folks left, that is) about getting Logkit compiled using Java6.
And then I'm really looking forward to finally meet Erik Hatcher in person. It must have been around five years since he started to commit to Ant.
path: /en/Apache/ApacheCon | #
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 | #
Over the last year I've been honored to be listed as a mentor for Ivy, which is a tool for managing project dependencies (and as a side effect downloading artifacts from repositories of different flavors, including Maven2) with tight integration into Ant.
Today the final votes have finished and Ivy now is an official subproject of Ant. Welcome on board!
For more information on Ivy see its Incubator Homepage until we are done migrating everything over to Ant.
path: /en/Apache/Ivy | #
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 | #