This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
what i have here is a freeform project in NB where i have bunch of targets in build.xml executed when building my project form within NB. one of those ANT targets has dependency on Xalan-J which my project has included. the in question target looks like this : <target name="compileadminsubtask"> <!-- Xalan-J Class Path : refer to it explicitly from each XSLT task. --> <path id="xalan.class.path"> <fileset dir="${ext.dir}/xalan-j"> <include name="*.jar" /> </fileset> </path> <!-- Generate introspection API for core administration components. --> <xslt basedir="${admin.defn.dir}" destdir="${admin.src.dir}" includes="**/*Configuration.xml" excludes="${exclude.ndb.xml}" style="${admin.rules.dir}/metaMO.xsl"> <regexpmapper handledirsep="true" from="^(.*)/([^/]+)Configuration\.xml$$" to="\1/meta/\2CfgDefn.java" /> <param name="base-dir" expression="${admin.defn.dir}" /> <classpath refid="xalan.class.path" /> </xslt> [ ... etc ... ] ${ext.dir}/xalan-j folder is a folder in my project containing Xalan-J jars, including xalan.jar itself. when this compileadminsubtask target is executed it reports that : [xslt] [Deprecated] Xalan: org.apache.xalan.processor.TransformerFactoryImpl then the build fails at later stage due to failed XSLT transformations. needless to say compileadminsubtask target works good and proper from the command line ie ant compileadminsubtask, and the build succeeds. the only workaround i have found is to add another target in my build.xml which would execute ANT on the same build.xml file with the target i need Xalan for, like this : <exec executable="${ant.home}/bin/${antcmd}" failonerror="true"> <arg value="-buildfile" /> <arg value="${ant.file}" /> <arg value="compileadminsubtask" /> <!-- Set classpath to workaround NetBeans Xalan conflict --> <env key="CLASSPATH" value="${ext.dir}/xalan-j/xalan.jar" /> </exec> apparently setting CLASSPATH then spawning another ANT workarounds the problem but i'd rather have a proper solution here instead. i do not think that NB should feed its own dependencies and environment into my ANT build, this is wrong and opens a door to other similar conflicts. NB should spawn a clean ANT with nothing more than specified in NB ANT preferences [ if anything ]. ie there should be no difference from invoking ANT from command line to invoking ANT from within NB as far as freeform project build is concerned.
For a variety of reasons NB runs Ant in-process. Normally this does not matter, but there can be bugs in various tasks which are tickled by this, and in particular JAXP factories are notoriously poorly written when it comes to class loaders. May or may not be possible to work around in NB; could also be an Ant bug, TBD.
Working for me on Ubuntu with JDK 6; script behaves the same when run from inside NetBeans (6.9 dev build) as from the command line (Ant 1.8.0): <project name="test182077" basedir="." default="x"> <target name="x"> <echo file="in.xml"> <![CDATA[ <build error="problem!"> <target name="whatever" time="1 second"> <message priority="info">hello...</message> </target> </build> ]]> </echo> <xslt in="in.xml" out="out.html" style="${ant.home}/etc/log.xsl"> <classpath path="/usr/share/java/xalan2-2.7.1.jar"/> </xslt> </target> </project> ---%<--- x: Processing /tmp/in.xml to /tmp/out.html Loading stylesheet /space/nb/curr/java/ant/etc/log.xsl BUILD SUCCESSFUL (total time: 0 seconds) ---%<--- I cannot find the string "[Deprecated]" in Ant sources so I can't guess where this is coming from. Reopen if you can produce a minimal, self-contained, reproducible test case I can try for myself. Be sure to check with Ant 1.8.0 in addition to 1.7.1; NB 6.9 bundles it but you can always temporarily use 1.8.0 in 6.8 by going to Tools > Options > Miscellaneous > Ant > Ant Home > Browse. Or the problem you are seeing might be specific to a particular version of Xalan-J, or be triggered only by certain <xslt> options, or versions of Java, etc. etc.
re-opening, still a problem, testcase with instructions on how to reproduce sent directly to responsible engineer.
Reporter confirms that problem appears only on Mac OS X.
Created attachment 95381 [details] ANT debug log from NB on Mac build
Created attachment 95382 [details] ANT debug log from cmd line on Mac build
Created attachment 95383 [details] ANT debug log from NB on Ubuntu build
i think i got to the bottom of this finally. its not NB issue at all but is actually pure Apple JDK issue. apparently Apple ships old version of Xalan with their JDK [for compatibility reasons judging by jar filename] and that version of Xalan get loaded instead of the newer one needed. more details : Mac [ Xalan Java 2.4.1 ] : java org.apache.xalan.xslt.EnvironmentCheck [Deprecated] Xalan: org.apache.xalan.xslt.EnvironmentCheck #---- BEGIN writeEnvironmentReport($Revision: 1.14 $): Useful stuff found: ---- version.DOM.draftlevel=2.0fd java.class.path=. version.JAXP=1.1 java.ext.dirs=/Library/Java/Extensions:/System/Library/Java/Extensions:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/ext version.xerces2=not-present version.xerces1=not-present version.xalan2_2=Xalan Java 2.4.1 version.xalan1=not-present version.ant=not-present java.version=1.6.0_17 version.DOM=2.0 version.crimson=present-unknown-version sun.boot.class.path=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jsfd.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Frameworks/JavaRuntimeSupport.framework/Resources/Java/JavaRuntimeSupport.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/ui.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/laf.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/sunrsasign.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jsse.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jce.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/charsets.jar version.SAX=2.0 version.xalan2x=Xalan Java 2.4.1 #----- END writeEnvironmentReport: Useful properties found: ----- # YAHOO! Your environment seems to be OK. java -verbose org.apache.xalan.xslt.EnvironmentCheck | grep EnvironmentCheck[Deprecated] Xalan: org.apache.xalan.xslt.EnvironmentCheck [Loaded org.apache.xalan.xslt.EnvironmentCheck from file:/System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/.compatibility/14compatibility.jar] Ubuntu [ No Xalan ] : java org.apache.xalan.xslt.EnvironmentCheck Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/xalan/xslt/EnvironmentCheck Caused by: java.lang.ClassNotFoundException: org.apache.xalan.xslt.EnvironmentCheck at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) Could not find the main class: org.apache.xalan.xslt.EnvironmentCheck. Program will exit. the solution is to either remove 14compatibility.jar completely or use Endorsed Standards Override mechanism as described here : http://xml.apache.org/xalan-j/faq.html#faq-N100EF essentially providing a newer version of Xalan for JDK to use instead. now i have no idea how i got it working via ant cmd line invokation in the first place, perhaps i had it in CLASSPATH or something, dunno. sorry for wasting your time like this but hopefully this bug can help other folks hitting same kinda issues in the future.
v/c