Thanks Vincent,
I prefer not to keep the names of jars in an external properties file
because of the unecessary maintenance and scope for stuff-ups. I like
the way that the servlet spec ensures that the webapp automatically picks
up all jars in the lib directory, and so I'm trying to make my build.xml
file do the same. If I want to test an updated jar, I'll simply switch
it into the lib dir.
I'm still struggling with this - the only way I can get things to work is
when the system classpath includes all jars. I've attempted all manner
of jar placements and classpath/classdef combinations now. Grrr.
I note that there are many posts on the ant-user list that relate to
classloading across tasks. I'll keep trying...
J.
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 7/23/01, 4:50:24 PM, "Vincent Massol" <[EMAIL PROTECTED]> wrote regarding
Re: Defining classpath within ant build file:
> Ah I see, I didn't understand your intent at first ... You don't need to
do
> that to get rid of shell scripts ! :-)
> Look at how it is done with Cactus build system is done, it doesn't use
any
> shell script ...
> Very quickly the idea is :
> - need to have Ant installed and all jars needed by standard and optional
> Ant tasks put in ${ANT_HOME}/lib (this means junit.jar there, yes)
> - need to create a build.properties file containing locations of other
> needed jars (that's because it is good to externalize locations of jar so
> that you can easily test your application with newer versions for
example).
> Read this file from your Ant build.xml file to initialize the properties.
> - then you cd in your directory where your build.xml is located and just
> have to type 'ant <target name>'. That's all !
> Have a look at Cactus CVS.
> Cheers
> -Vincent
> ----- Original Message -----
> From: "Jason Grant" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 23, 2001 12:23 AM
> Subject: Re: Defining classpath within ant build file
> Thanks Vincent,
> I'll see if I can work around this by writing helpers too.
> I want to dispense with the scripts because my application needs to run
> on different platforms, and so I don't want to maintain shell scripts for
> unix, batch scripts for Windows, etc., when ant already does a great job
> at assembling paths. Also, I'm coding under the Turbine framework, which
> no longer uses a wrapper script to invoke ant. Reintroducing the scripts
> seems like a backwards step to me, and I'm keen to reduce the
> maintenance, overhead during Turbine upgrades, platform-specific
> development & testing, etc.
> J.
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> On 7/23/01, 1:08:09 AM, "Vincent Massol" <[EMAIL PROTECTED]> wrote regarding
> Re: Defining classpath within ant build file:
> > Hi Jason,
> > Ant 2.0 will change that but for the time being it is not possible to use
> an
> > explicit classpath when defining a task that will call another task. For
> > example, in Cactus, what I have done is to write helper classes. For
> example
> > the startserver task is simply a wrapper around a helper class that has
> the
> > logic. This so that the runservertask will actually not call the
> startserver
> > task but rather it's helper. This is because as you mentionned, in Ant
> 1.x
> > it is not possible to call a task from another task when explicitely
> > defining a classpath (when using the taskdef task).
> > Note: The exception to this is when the second task to call is an Ant
> task
> > (i.e. located in an Ant package, can't remember which but I remember that
> an
> > Ant package was automatically added to the classloader class path,
> probably
> > org.apache.tools.ant.task).
> > I don't know what's wrong with your script.
> > Cheers,
> > -Vincent
> > ----- Original Message -----
> > From: "Jason Grant" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Sunday, July 22, 2001 2:29 PM
> > Subject: Defining classpath within ant build file
> > I have a question that relates to testing via taskdefs & classloaders
> > under ant.
> > I have not been able to conduct tests after defining a classpath within
> > ant's build.xml file. If I define the classpath externally (i.e. within
> > the shell that executes ant), I am able to conduct my tests. If I
> > instead define a classpath in either taskdefs, or in the targets
> > themselves, I get ClassNotFound exceptions.
> > Back when cactus was j2eeunit, Vincent explained that use of explicit
> > classpath entries in either taskdefs or targets causes ant to run each of
> > the tasks [having custom classpaths] under different classloaders, and so
> > it is not possible for one task to call another (as done by the cactus
> > server task) under these circumstances. This explains why things work
> > when the classpath is configured externally by the shell - all of the
> > tasks run under the same classloader.
> > I would now like to dispense with the use of a wrapper script that sets
> > up the classpath for me, and instead define the classpath within my
> > build.xml file. I want to use a combination of path and refid
> > statements, as shown below.
> > Suggestions appreciated.
> > Here's an example of what I'd like to do:
> > <!-- Build classpath -->
> > <path id="classpath">
> > <fileset dir="../lib">
> > <include name="**/*.jar"/>
> > </fileset>
> > <fileset dir="../../../../common/lib">
> > <include name="**/servlet*.jar"/>
> > </fileset>
> > </path>
> > ...
> > <taskdef name="runservertests"
> > classname="org.apache.commons.cactus.ant.RunServerTestsTask">
> > <classpath refid="classpath"/>
> > <taskdef/>
> > <taskdef name="junit"
> > classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask">
> > <classpath refid="classpath"/>
> > <taskdef/>
> > <taskdef name="batchtest"
> > classname="org.apache.tools.ant.taskdefs.optional.junit.BatchTest">
> > <classpath refid="classpath"/>
> > <taskdef/>
> > ...
> > <target name="run-tests">
> > <junit printsummary="yes" haltonfailure="yes" haltonerror="yes"
> > fork="yes">
> > <formatter type="plain" usefile="false"/>
> > <batchtest>
> > <fileset dir="${src.dir}">
> > <include name="**/*ServletTest.java"/>
> > </fileset>
> > </batchtest>
> > </junit>
> > </target>
> > <target name="tests" depends="init-tasks">
> > <runservertests testURL="http://localhost:8080";
> > startTarget="start_tomcat_40"
> > stopTarget="stop_tomcat_40"
> > testTarget="run-tests"/>
> > </target>
