On 06/01/2010 04:36 AM, Andrew John Hughes wrote:
In the langtools build, the genstubs tool is passed a classpath:<genstubs srcdir="${import.jdk.src.dir}" destdir="${build.genstubs.dir}" includes="${import.jdk.stub.files}" fork="true" classpath="${build.toolclasses.dir}:${build.bootstrap.dir}/classes:${ant.home}/lib/ant.jar" /> which it uses for a forked process that runs genstubs itself. However, if fork is set to false the classpath given by: <taskdef name="genstubs" classname="GenStubs$$Ant" classpath="${build.toolclasses.dir}/"/> which seems to work in some cases, but only if Ant has access to the 1.6 javax.tools classes. Even if these classes are available, they will be the ones belonging to the boot VM and not the bootstrap classes. Should this classpath not be set to the same as that passed to genstubs as in http://hg.openjdk.java.net/icedtea/jdk7/langtools/rev/681f1f51926f ?
Possibly. Getting genstubs to work was enough of a challenge that I was pleased to get it running with fork=true without taking it to the next step of fork=false. One minor issue is that putting langtools classes on a classpath is generally not acceptable for anyone building on a Mac -- which is why you see such liberal use of the bootclasspath in the langtools build.xml file.
Also, I'd be surprised if you need the ant classes on the classpath for a taskdef -- are they not available anyway?
Finally, I'm not sure if this is an issue or if this assumption is already implicit in the rest of the Ant file, but by putting the langtools classes on the taskdef classpath, you are assuming that Ant's JVM can handle them -- which is presuming a certain level of JVM used to run Ant.
-- Jon
