> the classpathref basically points to a bunch of support jars the ultimate > java class needs (e.g. antlr.jar) but not rt.jar (who ever needs to add > rt.jar to their classpath?)
Well, as I understand it the crux of the matter is that your task is going to be loaded with the system classpath if it's on it, in which case it'll be able to get to rt.jar just fine. But now you're going to have problems getting to other stuff that's *not* on the system classpath. If you can get all of your tools into a jar file to support your task, then you can impose the same sort of rules that other stuff imposes for similar reasons: have users ensure that your .jar file is on the system classpath (most simply, have it be copied into the ant lib). In my case, I went the other way and set up my application build to have the Java libraries on my internal build classpath. But then my tasks are quite specific to my application and uninteresting outside of my own build, so having control of the build classpath is not a problem for me. -- [ you are my main foo ] Mike McNally -- [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
