Sometimes the Java community, or more specifically the people that write Java open source software, drive me nuts!
For the past couple of week I’ve been trying to build a new version for the Jetty package based on the current Jetty6 package from JPackage(1), and in the process combating its hellish dependency tree and the way open source Java projects build opon each other in a complicated, confusing and often circular manner.
Examples for circular dependencies are varied and not that interesting – In order to build Jetty you need some third party libraries, which in order to build them you need a provider of Servlet API 2.4, of which there are several candidates including the current version of Jetty (you need to build Jetty6 in order to be able to build Jetty6), the previous version of Jetty (you need to build Jetty5 in order to build Jetty6 – a bit less silly but still silly) or Tomcat (you need to build the competitor to Jetty in order to build Jetty – quite silly even if its open source we are talking about).
This is not the worst circular dependency – they were others far worst last time I tackled something like this (a couple of years back), like you need to have Jakarta’s commons-httpclient installed in order to be able to build Jakarta’s commons-httpclient. Luckily it appears they got that fixed.
Continuing to work on this, here is another problem I encountered: In order to build Jetty 6 you need wadi 2, which in order to build you need Maven 2 and specifically the Mojo Maven 2 plugin for javacc, which in order to build you need Xfire, which in order to build you need Jetty 6. Lather, Rinse, Repeat.
But what prompted this rant was another very common problem with Java open source project – feature creep in the worst kind of way: I’m trying to build the JAXB package, which is a simple interface to parse and build XML. It depends on args4j which is described as “a small Java class library that makes it easy to parse command line arguments”. First I’ve heard of it(2) but oh well, lets try to build it. Well, apparently in order to build it it requires Saxon which is an XSLT processor(3). why ?!?
Noticed the “small” part that I highlighted earlier? In my dictionary “small” includes many properties, one of which is “Does not have large or complex external dependencies”.
And you get this all the time when trying to build Java libraries and applications – up until now I had to install 2 versions of groovy, 2 versions of saxon, 3 versions of the Java development kit itself(4) and I had to build and install Xalan twice (once for bootstrapping and a second time to actually get the xsltc processer I needed).
A few years back I ranted about this in an email to JPackage maintainer Ralph Apel at which point he replied that this is the best they can do to fight the insanity in the upstream(5).
- an excellent excellent project that is operated by talented people in what I can only guess is what little free time they have [↩]
- why can’t they use gnu-getopt like everyone else? [↩]
- as well as maven which is a huge headache in and of itself and requires and required the installation of 42 packages, but all the cool kids are using it these days so I can’t say anything about it [↩]
- seems that most stuff I need requires java 1.5.0 and nothing later while we use 1.6 and the system itself requires 1.4 [↩]
- For those not “in the know”, “upstream” in open source speak means the project that generates the source code we build upon [↩]