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 | #