Phil Steitz wrote:
I would not recommend hacking the maven-generated build.xml. I have run into this same problem before with other scripts that use the optional Junit tasks (e.g. struts build.xml). You need to copy junit.jar to ANT_HOME/lib and get this defined in the classpath. When I run ant from the command line, I always wrap it in a script that explicitly sets the classpath (and the JDK). The build.sh that I used with the original (pre-maven-generated build.xml) still works for me. I don't think that it is unreasonable to expect users who run ant from the command line to set the classpath and get junit.jar into ANT_HOME/lib. A note somewhere indicating the second requirement would be a good idea.
Phil
Yes, I now see, "we can either toture you with the cat-o-nine-tails or the man-of-war, it your choice!"
Basically, I was considering altering the jelly script in the maven plugin and submitting it to them for an update. But now I see, even if I include the taskdef in the generation, if the user already has ant-optional installed, the task can't load. It still attempts to get the junit task from the JVM base class loader first and the junit task can't get to the child classloader to get the junit library and we're back to the same problem we started with.
I like Jellys classloading model more than Ant's. This sort of thing can be done very easily in Jelly.
Your right, the user has got to setup junit in Ant themselves. -Mark
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
