Re: [cross-project-issues-dev] Change in the default java on build.eclipse.org
Ed : No, this was seen directly on build.eclipse.org, and our
failing build (ecoretools) is not on an HIPP (as far as I know since
I am not the main releng there).|
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
$JAVA_HOME -> /usr/lib64/jvm/java ->
/etc/alternatives/java_sdk -> /usr/lib64/jvm/java-1.5.0-gcj ->
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.
On 18/12/2013 08:43, Dennis Hübner
After trying around with combination of different processors
and ant versions
I gave up and switched to
A 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
On 17.12.2013 10:33, Laurent Goubet wrote:
With Luna M4, we've begun to see "strange" failures in
our ant promoters :
no xsl:version attribute on literal result node
This 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/console
It seems like this same failure also happened for EMF :
I ultimately tracked this down to our "JAVA_HOME"
pointing to a 1.5.0 gcj version of the jre on 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
Strangely enough, this isn't the version used in our
> 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
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
Likewise, 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?
cross-project-issues-dev mailing list
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
Am Germaniahafen 1
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang
Neuhaus, Dr. Georg Pietrek, Jens Trompeter,
Aufsichtsrat: Dr. Burkhard Igel (Vors.),
Stephan Grollmann, Michael Neuhaus