Eclipse, Ant and classloading

[Ken Pelletier]

I have an ant target that runs a java task to generate some code from xml. Run from ouside Eclipse, either from the command line or a build tool like anthill, all is well.
I'm using 1.4.1 jvm on OS X and Linux, and have placed the xmlAPIs.jar and xercesImpl.jar in the $JAVA_HOME/lib/endorsed directories so that the classloader will prefer this parser over crimson, the built-in 1.4.1 parser.
When running the ant target in Eclipse, however, I get:
java.lang.NoClassDefFoundError: org/xml/sax/SAXException
The same appears to be true for classes in $JAVA_HOME/lib/ext (mail.jar, activation.jar). The <javac> task isn't seeing them when run from Eclipse.
What is it about running ant under Eclipse that is causing the normal classloading delegation to be circumvented?
Eclipse 2.1.1, ant 1.5.3

[David Hibbs]

The catch is that you're launching a Java app from inside an app that has its own Classpath and ClassLoaders. As such, you need to tell the app a little more about the classpath. Here's how to do that.
Select Window->Preferences.
From the tree, expand "External Tools" and select "Ant".
In the panel at the right, select "Add Jar" and navigate to
<eclipse_home>/plugins/org.apache.xerxes_x.y.z and select all the jars.
OK the dialog.
You're ready to roll.

[Ken Pelletier]

Thanks for the response. I've already been down that path, however, and no joy.
I do have references to xercesImpl.jar and xmlAPIs.jar in the ant prefs.
Following another post elsewhere, I even tried copying them from the xerces plugin location into the ant plugin location - no effect.
I also tried running my own ant dist as opposed to the plugin by changing the ant home in Eclipse. Same symptom.
My <java> target in the ant build also uses fork="true", which should run it in a separate JVM, with its own classloaders. Elsewhere I've found (eg: JUnit) this to get around non-delegating classloaders.
I also have the xerces jars in my $JAVA_HOME/lib/endorsed, which has been rumored to be a problem, but I find that removing them from there also does not solve this problem.
Any further thoughts on this?

[David Hibbs]

Ahhh. In that case, you need to add a nested classpath element to your java target to ensure that it's on the classpath. Try something like this:

  
    <classpath>
        <pathelement location="xerxes_home/xerxes.jar"/>
        <pathelement path="java.class.path"/>
    </classpath>

[Ken Pelletier]

Thanks!
I did a bit of further investigating and it appears that the 3.0M3 build does not have this problem with xerces being installed the system-wide 1.4.x way; lib/endorsed. At least it does not break as it did in 2.1.1.
I already have continuous checkout/build/unit test running for this project on various platforms. I'm trying my darndest to not have to make any build changes that are purely to accomodate Eclipse... so far it's been a challenge. ;-)
There was another wildcard in this that lowered the signal-to-noise for me: the cvs checkouts done via eclipse were munging jar files due to keyword expansion (i presume). While this wasn't the case on any other cvs checkout, jar files should have been checked in with -kb anyway, so I was happy to correct that and Eclipse now has not trouble with them.
Thanks - I'm optimistic that I can become productive in Eclipse quickly. I'm just evaluating whether I can make the jump. So far, so good.

[David Hibbs]

Another possibility is to reconsider whether the fork="true" call is really required. If you don't have to fork, then xerxes should still be on the classpath.
I haven't had any problems with jar files and CVS... maybe someone else checked them in with the wrong expansion mode? I don't recall making any changes at work (in WSAD) or at home (in Eclipse 2.0--I really need to step up!) to make things work.
I suspect you'll be very happy with Eclipse. I know I am!