Community
Participate
Working Groups
Build Identifier: Version: Indigo Service Release 1 Build id: 20110916-0149 When building a project with Junit tests with ant from the Eclipse IDE using Java 6 build 32 or later, the following error occurs: [junitreport] Processing /MYPATH/junit/html/TESTS-TestSuites.xml to /var/folders/Hh/HhhDpmqxFISJ84nX-yGYY++++TI/-Tmp-/null191644350 [junitreport] Loading stylesheet jar:file:/MYPATH/eclipse/plugins/org.apache.ant_1.8.2.v20110505-1300/lib/ant-junit.jar!/org/apache/tools/ant/taskdefs/optional/junit/xsl/junit-frames.xsl [junitreport] : Error! The first argument to the non-static Java function 'replace' is not a valid object reference. [junitreport] : Error! Cannot convert data-type 'void' to 'reference'. [junitreport] : Fatal Error! Could not compile stylesheet [junitreport] Failed to process /MYPATH/junit/html/TESTS-TestSuites.xml Here are configurations that have failed: Windows 7, Eclipse 3.6.2 32-bit, JDK 1.6.0_32, Ant 1.7.2, Junit 4.8.1 Windows 7, Eclipse 3.7.2 32-bit, JDK 1.6.0_32, Ant 1.7.2, Junit 4.8.1 Windows 7, Eclipse 3.7.2 32-bit, JDK 1.6.0_32, Ant 1.7.4 (from Apache, current), 4.8.1 Mac 10.6, Eclipse 3.7.1 32-bit, JDK 1.6.0_33, Ant 1.7.2, Junit 4.8.1 As reported from this StackOverflow question (http://stackoverflow.com/questions/10536095/ant-junit-build-error-inside-eclipse), builds succeed using the same ant script when run from outside of Eclipse. On Windows, my current workaround is to use Java 6 build 31; however, this is not a satisfying solution. On Mac, Apple has updated Java to build 33 and rolling back Java is not straight forward. Reproducible: Always Steps to Reproduce: 1. Build a project with Junit tests with ant from the Eclipse IDE 2. 3.
Another configuration that failed: Windows 7, Eclipse 4.2 32-bit, JDK 1.6.0_33, Ant 1.7.3, Junit 4.8.1
Correction for Comment #0: A headless build fails in the same manner using antRunner in Eclipse. Mac 10.6, Eclipse 3.7.1 32-bit, JDK 1.6.0_33, Ant 1.7.2, Junit 4.8.1 "${ECLIPSE}" --launcher.suppressErrors -noSplash -clean -data "${ECLIPSE_WORKSPACE}" \ -vm "${JAVA}" -Dbuild=release -Dbuild.auto=true \ -application org.eclipse.ant.core.antRunner -buildfile "${BUILDFILE}"
I confirm the same problem with: Windows 7, Eclipse 3.7 (Indigo) 32-bit, JDK 1.6.0_32, Ant 1.8.4, Junit 4.10 I had to revert back to JDK 1.6.0_31. Thanks, Ioannis
This works fine with jdk6_31, jdk7_02, and IBM Java SDK 7.0 SR1, but it fails with current Oracle Java releases (jdk6_33 and jdk7_05). XSLT instructions like this one have a problem when the Ant script is started from Eclipse: <xsl:param name="tmp1" select="stringutils:replace(string($string),'\','\\')"/> However, I just verified that this works fine with jdk7_05 when I launch Ant from the command line: -showversion -classpath .;C:\e\i\4.3-I-builds\plugins\org.apache.ant_1.8.3.v20120530-0730\lib\* -Dant.home=C:\e\i\4.3-I-builds\plugins\org.apache.ant_1.8.3.v20120530-0730\lib\ org.apache.tools.ant.Main -f runAllTests.xml applyStylesheet The bug is somewhere in our InternalAntRunner, or in some code that is run by the InternalAntRunner. I suspected it could be the AntSecurityManager, but commenting that one out doesn't help. I'm investigating. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167657 could be related.
This TypeCheckError causes the problem. The friendly FunctionCall.typeCheck(SymbolTable) line: 385 swallows this stacktrace: Error checking type of an expression at an unknown location. The first argument to the non-static Java function 'replace' is not a valid object reference. at com.sun.org.apache.xalan.internal.xsltc.compiler.FunctionCall.typeCheckExternal(FunctionCall.java:542) at com.sun.org.apache.xalan.internal.xsltc.compiler.FunctionCall.typeCheck(FunctionCall.java:382) at com.sun.org.apache.xalan.internal.xsltc.compiler.Param.typeCheck(Param.java:158) at com.sun.org.apache.xalan.internal.xsltc.compiler.SyntaxTreeNode.typeCheckContents(SyntaxTreeNode.java:493) at com.sun.org.apache.xalan.internal.xsltc.compiler.Template.typeCheck(Template.java:295) at com.sun.org.apache.xalan.internal.xsltc.compiler.SyntaxTreeNode.typeCheckContents(SyntaxTreeNode.java:493) at com.sun.org.apache.xalan.internal.xsltc.compiler.Stylesheet.typeCheck(Stylesheet.java:657) at com.sun.org.apache.xalan.internal.xsltc.compiler.Parser.createAST(Parser.java:408) at com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:369) at com.sun.org.apache.xalan.internal.xsltc.compiler.XSLTC.compile(XSLTC.java:454) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:852) at org.apache.tools.ant.taskdefs.optional.TraXLiaison.readTemplates(TraXLiaison.java:300) at org.apache.tools.ant.taskdefs.optional.TraXLiaison.createTransformer(TraXLiaison.java:317) at org.apache.tools.ant.taskdefs.optional.TraXLiaison.transform(TraXLiaison.java:178) at org.apache.tools.ant.taskdefs.XSLTProcess.process(XSLTProcess.java:819) at org.apache.tools.ant.taskdefs.XSLTProcess.execute(XSLTProcess.java:407) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.Target.performTasks(Target.java:413) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.eclipse.ant.internal.core.ant.EclipseDefaultExecutor.executeTargets(EclipseDefaultExecutor.java:32) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:672) at org.eclipse.ant.internal.core.ant.InternalAntRunner.run(InternalAntRunner.java:498) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.eclipse.ant.core.AntRunner.run(AntRunner.java:378) at org.eclipse.ant.internal.launching.launchConfigurations.AntLaunchDelegate$1.run(AntLaunchDelegate.java:298) at java.lang.Thread.run(Thread.java:722)
In jdk7_02, the _namespace_format in com.sun.org.apache.xalan.internal.xsltc.compiler.FunctionCall.typeCheckExternal(SymbolTable) is NAMESPACE_FORMAT_CLASS. This was set in FunctionCall.typeCheck(SymbolTable) line: 358, where ObjectFactory.findClassLoader() returned an AntClassLoader. In jdk7_05, Oracle changed that line to use Class.forName(className) instead of ObjectFactory.findClassLoader() iff a security manager is active. This throws a ClassNotFoundException, and sets _namespace_format to NAMESPACE_FORMAT_PACKAGE, which later causes the wrong TypeCheckError from comment 5. => This is a bug that Oracle introduced, and I don't see a way to work around it in Eclipse.
This one is fixed by apache ant: https://issues.apache.org/bugzilla/show_bug.cgi?id=51668
Thanks for the link. Unfortunately, this patch didn't make it into Ant 1.8.3 nor 1.8.4. And I still think this is a bug in the JDK that should be fixed there.
The bug was introduced with Oracle jdk6_32 and jdk7_04 here: http://java.net/projects/jaxp-sources/sources/svn/revision/3040 The Ant fix from comment 7 apparently doesn't fully address this problem when a SecurityManager is present.
Assigning to me to make sure I don't lose track of this bug. If anybody has connections to Oracle, please push them to look at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167657 or at this bug.
Konstantin, do you have an idea how best to push the Oracle JDK team to fix the bug they introduced (comment 6)?
Also causes bug 390494.
I finally found a hack to work around the bug in Oracle's XSLT implementation. To replace the broken transformer with the original org.apache.xalan, you have to add this to the vmargs when running the Ant build: -Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl -Xbootclasspath/a:${project_loc:/org.apache.xalan} -Xbootclasspath/a:${project_loc:/org.apache.xml.serializer} You can check out the two org.apache.* bundles from Orbit CVS or get them from http://download.eclipse.org/tools/orbit/downloads/ (or maybe they are already in your plugins folder). If you use the JARs, then replace the ${project_loc:*} so that you have the full OS path to the org.apache.* bundle there.
There are two work arounds mentioned in bug 390494. Using the bootclasspath method as Paul mentioned, plus another using -Djava.ext.dirs to specify location of xalan jars. So, a). Don't think this should be "blocker" any longer (since a workaround exist). and b) think this should be closed as "not eclipse". I've changed severity, but will leave to "ant team" to resolve as "not eclipse" if they agree.
hallo all, i am new to ant, and i have the same problem. i saw your comment to the work round bug in Oracle's XSLT implementation To replace the broken transformer with the original org.apache.xalan. in order to add the vmargs, i am not experienced in ant, can you please give me an example how should the ${project_loc:/org.apache.xml.serializer} looks like. specialy the "project_loc" should i add the tasks to the Junit target? thanks lissan
https://issues.apache.org/bugzilla/show_bug.cgi?id=54641
https://issues.apache.org/bugzilla/show_bug.cgi?id=54641#c2 mentions a 'fix' proposed on stack overflow. The Ant folks are testing it now - for the release in Ant 1.9.0
> https://issues.apache.org/bugzilla/show_bug.cgi?id=54641#c2 mentions a 'fix' That fix works and is a good workaround for the Oracle bug in latest JREs. If you can't wait for Ant 1.9.0, you can use the stylesheets from http://svn.apache.org/viewvc?view=revision&revision=1453414 . See the example at the end of http://ant.apache.org/manual/Tasks/junitreport.html for how to specify custom stylesheets.
(In reply to comment #18) > If you can't wait for Ant 1.9.0, ... Actually, it looks like the fix will not make it into Ant 1.9.0.
(In reply to comment #19) > it looks like the fix will not make it into Ant 1.9.0. No. But the release manager for 1.9.0 has said he hopes to release 1.9.1 pretty soon.
Bug 395421 - Update to Ant 1.9.1 is assigned and currently scheduled for Eclipse 4.4. This bug should be fixed with the next Ant upgrade.
