Dennis : M4 is the first time we see this failure, and we had never changed the default VM before.
The default alternative (I'm talking about ubuntu's "update-alternatives" and the related set of utilities) for Java has changed somehow : JAVA_HOME was pointing to /usr/lib64/jvm/java which in turn is a symbolik link that references the alternative : /etc/alternatives/java_sdk. If we follow the whole set of symbolic links :
$JAVA_HOME -> /usr/lib64/jvm/java -> /etc/alternatives/java_sdk -> /usr/lib64/jvm/java-1.5.0-gcj -> /usr/lib64/jvm/java-1.5.0-gcj-4.3-1.5.0.0
Since this is only failing now and we have not changed our ant files for years, I believe that the link to the java alternative was not pointing towards this "gcj" implementation for M3 and all releases before that. This can be worked around by just exporting our own JAVA_HOME instead of depending on the system's alternatives... but that also means making sure we never use the default in our build jobs and all other tasks that may use 'java' on the server.
Laurent Goubet Obeo On 18/12/2013 08:43, Dennis Hübner wrote:
Hi all,I had the same problem with build.eclipse.org <http://build.eclipse.org> last week. After trying around with combination of different processors and ant versionsI gave up and switched to the /usr/lib64/jvm/java-1_6_0-ibm-1.6.0We really need a better JVM default, for HIPPs and build.eclipse.org <http://build.eclipse.org>.Best regards, Dennis.Am 17.12.2013 um 22:38 schrieb Ed Willink <[email protected] <mailto:[email protected]>>:Hi LaurentA long time ago GNU Java was the almost unuseable default for vanilla Unix systems.Have you perhaps just switched to a new unconfigured platform such as a HIPP where the defaults are different?Regards Ed Willink On 17.12.2013 10:33, Laurent Goubet wrote:Hi,With Luna M4, we've begun to see "strange" failures in our ant promoters :javax.xml.transform.TransformerConfigurationException: no xsl:version attribute on literal result nodeThis happened for us on the ant promoters for EMF Compare and Acceleo, and we also had a random failure on one of our builds : https://hudson.eclipse.org/hudson/job/emf-ecoretools-1.1.0/51/consoleIt seems like this same failure also happened for EMF : https://bugs.eclipse.org/bugs/show_bug.cgi?id=420481I ultimately tracked this down to our "JAVA_HOME" pointing to a 1.5.0 gcj version of the jre on build.eclipse.org <http://build.eclipse.org> :> $JAVA_HOME/bin/java -version java version "1.5.0" gij (GNU libgcj) version 4.3.4 [gcc-4_3-branch revision 152973] Strangely enough, this isn't the version used in our PATH : > java -version java version "1.6.0_27" Java(TM) SE Runtime Environment (build 1.6.0_27-b07) Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)after exporting a more appropriate version, ours promoters started to work anew :> export JAVA_HOME=/shared/common/jdk-1.6.x86_64 > export JAVA_ROOT=/shared/common/jdk-1.6.x86_64 > export JAVA_BINDIR=/shared/common/jdk-1.6.x86_64/binLikewise, changing our failing hudson job's configuration from "(Default)" to an explicit "Java 6 R 30", the build worked like a charm.Was this change to java 1.5.0-gcj announced somewhere, or is that an unexpected change?Laurent Goubet Obeo_______________________________________________ cross-project-issues-dev mailing list[email protected] <mailto:[email protected]>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-devDennis Hübner Xtext Commiter / Build Engineer Mobile: +49 (0) 151 / 17 39 67 07 Telefon: +49 (0) 431 / 990 268 70 Fax: +49 (0) 431 / 990 268 72 itemis AG Niederlassung Kiel Am Germaniahafen 1 24143 Kiel http://www.itemis.de/ Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian NeusAufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
<<attachment: laurent_goubet.vcf>>
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
