The Maven build for applications fails with JDK 1.5 because the class
org.apache.xalan.processor.TransformerFactoryImpl cannot be found. The failure
is connected with this line of maven.xml in the applications project: 

<maven:maven descriptor="${basedir}/server/project.xml"
        goals="astrogrid-build-artifact" ignoreFailures="false" />

In maven.xml in the server project there is this line:

${systemScope.setProperty('javax.xml.transform.TransformerFactory',
       'org.apache.xalan.processor.TransformerFactoryImpl')}

That works for JDK 1.4.x but fails for JDK 1.5.x; SUN ship a different set of
classes for XSLT.  The setting for JDK 1.5.x is

${systemScope.setProperty('javax.xml.transform.TransformerFactory',
       'com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl')}

This is a system property on the JVM, so it really shouldn't be hard-coded in
the maven.xml. However, commenting out the declaration in maven.xml doesn't
work; the JDK doesn't ptovide a default.

Maven can be made to work by removing the
javax.xml.transform.TransformerFactory
declaration from all the maven.xml in the sub-projects and defining it as a
system property (-Djavax.xml.transform.TransformerFactory=...) in the script
that runs maven: maven or maven.bat, according to platform. If we do it that
way, then the same maven.xml will work for both JDKs and the fix can be made
locally. The fix is also in one place for all maven projects.

I agree that this needs addressing.

However, rather than tweaking the installation of maven (making both our code
and our machines non-portable), we can fix this in our own maven scripts.

Rather than hard code the class name of the XSLT transformer, we should change
our scripts to use a property.

    <ant:echo message="Fixing JAXP properties ...."/>
    <core:set var="TransformerFactory"
value="${org.astrogrid.maven.xml.transform}"/>
    <core:expr
value="${systemScope.setProperty('javax.xml.transform.TransformerFactory',
TransformerFactory)}"/>

(the set before the expr is because jelly - it works, don't ask)

We can then set the property in our local ${user.home}/build.xml properties

#
# Set the XSLT transformer to use.
# JDK 1.4.x - org.apache.xalan.processor.TransformerFactoryImpl
# JDK 1.5.x - com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
org.astrogrid.maven.xml.transform=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
 
This enables us to have both JDK 1.4 and JDK 1.5 installed on a machine, and we
only need to change a build property when we swap between them.

Ideally, we should remove all instances of the original 'fix' from our various
maven scripts, and put one instance of the new 'fix' in our global
maven-base/maven.xml so that all sub-projects use the same one.

Dave's idea is clearly better than my hack.

Another option would be to fix Maven 1.x (or the relevant plugin of same) so
that it sets the property according to the JDK.

However, see also bug 1078. It looks like there is some Apache extension to JAXP
that Maven needs. It may be necessary to override the XSLT installation in JAXP
by making a dependency on the xalan jar in all projects that use XSLT from
Maven.  I'll test this. If the fix works, then I favour implementing Dave's
global property but hardcoding the value to favour the JDK 1.4 implementation of
JAXP.

Branch integration-gtr-1075 is created to work on this. I've changed the
category to build and integration testing since it's a generic problem.

Bad news, I'm afraid.

Because of bug 1078, Maven cannot be switched to the XSLT implementation that
comes with Java 5. Thus, Dave's solution with the properties isn't a complete
fix (it would be enough for some projects and not for others, depnding on what
XSLT features the projects use).

Furthermore, it doesn't help to add the missing jar as a project dependency. If
 it's added this way, then the part of Maven running XSLT doesn't see the extra
classes.

The work-around for both this bug and bug 1078 is to put xalan-2.6.0.jar into
$MAVEN_HOME/lib/endorsed/ . Maybe we can get this put into Maven 1.0.3 or Maven 1.1.

I'm accepting this, implying two actions:

1. Log a bug on Maven at Jakarta.

2. Eventually factor out the choice of transformer as suggested by Dave s.t. we
can switch easily when Maven supports standard transformers.

I don't expect the second action to get finished quickly.

should we be compiling with JDK 1.5? is this safe for backwards compatability? 
 

The use of J2SE 5 was debated a while ago (2004). The conclusion was that we
should start using it immediately, so as to check compatibility, but should not
use any of the new features such as generics. At that time, nobody knew about
the problems with XSLT.

If we didn't have the XSLT problem, we could use J2SE 5 but set Maven properties
such that the bytecodes are generated for J2Se 1.4. We should probably set these
properties anyway. As things stand, we can't use J2SE 5 at all.

The Maven project claim to have fixed this problem in Maven 1.1 (which is not
yet available).

Not worth chasing this until we have Maven >1.0.2 that works with Java 5.

builds with java 1.5 and maven 2 if that is any good

(In reply to comment #12)
> builds with java 1.5 and maven 2 if that is any good
> 

Fine by me.