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 | #
Since I get a lot of Google traffic by people looking for information on MSBuild, I should point to the new MSBuild homepage at Channel 9 as well as the Wiki (RSS 2.0 feed). Via Jomo Fisher.
path: /en/dotNet/msbuild | #
It's that time of the year again. All over Germany kids are making lanterns and (re-)learn the songs of the season. Mine are no exception.
This year's lantern form of choice involves balloons, colored transparent paper and paste, lots of paste. This here comes close, but my kids use smaller snippets of paper, several different colors and probably more paste. I'm not sure what they enjoy more - the sticky fingers or the part of the build process that involves a needle and ends with a bang.
We are booked for at least three if not five lantern parades over the next few weeks, so cold feet and wet noses are to be expected.
path: /en/Germany/culture | #
I've updated the jar file containing my Antlib of tasks that may be useful for people developing .NET applications with Ant. There is no new functionality, the old jar was missing a class that made it unusable with Ant 1.6.2.
Many thanks to Doug Case for letting me know.
path: /en/Apache/Ant/dotnet | #
The MSBuild team is looking for a software developer experienced in build technologies and practicing an agile development style (via Chris Flaat).
Maybe one of my two readers qualifies for the job and even is interested.
path: /en/dotNet/msbuild | #
Sebastian Bergman who ported JUnit to PHP points to a few other ports and in his comments there are even more links. Funny to see so many Apache Java projects in the list - including Torque, Struts and Cocoon.
Steve points to Phing. Ant rewritten in PHP.
path: /en/Apache/Ant | #
Matt needs a way to detect Ant 1.6.2 at runtime. Since we only added XML namespace aware DynamicConfigurators in 1.6.2 this here
<available property="Ant-1.6.2-or-later"
classname="org.apache.tools.ant.DynamicConfiguratorNS"/>
should do.
path: /en/Apache/Ant | #