[math] junit and ant build

["Mark R. Diggory" <md...@latte.harvard.edu>]

I've always been using Eclipse/Ant to build the project. In which case 
JUnit is already present on the classpath for Ant (Either that or adding 
it was just so damn simple I forgot I did it). I was just testing Ant 
outside of Eclipse from the command line and I noticed that it fails 
because junit isn't installed in the same directory as ant-optional.jar. 
This is something I can easily fix by placing a junit.jar in the 
ANT_HOME/lib directory, but....

This seems wierd that it is always the case that the ant build won't 
work the first time through. The maven generated build downloads that 
junit jar, but because the way Maven generates the build.xml, it doesn't 
generate a new classpath and use a taskdef to define the junit task with 
the new classpath info to effectively run the junit task. It seems 
logical that if JUnits going to be automatically download as a 
dependency, the Ant script should be setup properly to use it. I though 
to myself, maybe it was shortsighted of Maven to not do this in the 
generated build.xml.

Should we expect anyone who wants to build the project to properly setup 
JUnit in Ant before hand? Or should we try to find a way to get the 
"downloaded" junit into the classpath for the junit task? We have to be 
carefull here because we're using  Maven to generate the build.xml, this 
limits me from just going in and directly changing it because it'll just 
get overwritten later when the build.xml is updated by maven.

-Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] junit and ant build

["Mark R. Diggory" <md...@latte.harvard.edu>]

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] junit and ant build

[Phil Steitz <ph...@steitz.com>]

Mark R. Diggory wrote:
> I've always been using Eclipse/Ant to build the project. In which case 
> JUnit is already present on the classpath for Ant (Either that or adding 
> it was just so damn simple I forgot I did it). I was just testing Ant 
> outside of Eclipse from the command line and I noticed that it fails 
> because junit isn't installed in the same directory as ant-optional.jar. 
> This is something I can easily fix by placing a junit.jar in the 
> ANT_HOME/lib directory, but....
> 
> This seems wierd that it is always the case that the ant build won't 
> work the first time through. The maven generated build downloads that 
> junit jar, but because the way Maven generates the build.xml, it doesn't 
> generate a new classpath and use a taskdef to define the junit task with 
> the new classpath info to effectively run the junit task. It seems 
> logical that if JUnits going to be automatically download as a 
> dependency, the Ant script should be setup properly to use it. I though 
> to myself, maybe it was shortsighted of Maven to not do this in the 
> generated build.xml.
> 
> Should we expect anyone who wants to build the project to properly setup 
> JUnit in Ant before hand? Or should we try to find a way to get the 
> "downloaded" junit into the classpath for the junit task? We have to be 
> carefull here because we're using  Maven to generate the build.xml, this 
> limits me from just going in and directly changing it because it'll just 
> get overwritten later when the build.xml is updated by maven.

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

> 
> -Mark
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org