You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by David Corbin <dc...@machturtle.com> on 2000/12/23 22:22:35 UTC

Setting classpath

Are there any plans to allow Ant to "set the classpath" for particular
tasks?  I find it extremely annoying to have to set the classpath
outside of ant.
-- 
David Corbin 		
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@machturtle.com

Re: Setting classpath

Posted by Nico Seessle <Ni...@epost.de>.
----- Original Message -----
From: "David Corbin" <dc...@machturtle.com>
To: <an...@jakarta.apache.org>
Sent: Sunday, December 24, 2000 1:57 PM
Subject: Re: Setting classpath


> > > Is there anyway to refer to the classpath that ant's VM was invoked
> > > with?
> > You can refer to it using java-properties, but I don't think you can use
> > this to set up a classpath (but I have not tried it :-) )
> How does one refer to java-properties?  Is that the same as other "ant"
> properties, explicitly defined in the build.xml.
>
Ant is doing this in it's own build.xml (at least it seems so):

    <junit printsummary="no" haltonfailure="yes" fork="${junit.fork}">
      <jvmarg value="-classic"/>
      <classpath>
        <pathelement location="${lib.dir}/${name}.jar" />
        <pathelement location="${build.tests}" />
        <path refid="classpath" />
        <pathelement path="${java.class.path}" />
      </classpath>

Nico



Re: Setting classpath

Posted by David Corbin <dc...@machturtle.com>.
Nico Seessle wrote:
> 
> ----- Original Message -----
> From: "David Corbin" <dc...@machturtle.com>
> To: <an...@jakarta.apache.org>
> Sent: Sunday, December 24, 2000 2:32 AM
> Subject: Re: Setting classpath
> 
> > And, I've discovered, when you set the classpath for the junit task, you
> > have to add both optional.jar and ant.jar to the classpath (at least you
> > do if you have "fork" set).
> 
> What are you testing? And what is Ant's reaction if you don't include these
> two jar's in the classpath? (ClassNotFoundException? With what class?)

Yes.  ClassNotFoundExceptions.

org/apache/tools/ant/taskdefs/optional/junit/JUnitTestRunner


When I re-checked, I found that I was wrong about ant.jar. optional.jar
and (of course) junit.jar are necessary.  But it seems these are both
necessary to define the taskdef (as I recall, though my memory hasn't
been great lately), they ought to be included automatically.
> 
> > Is there anyway to refer to the classpath that ant's VM was invoked
> > with?
> You can refer to it using java-properties, but I don't think you can use
> this to set up a classpath (but I have not tried it :-) )
> 

How does one refer to java-properties?  Is that the same as other "ant"
properties, explicitly defined in the build.xml.

> Nico

-- 
David Corbin 		
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@machturtle.com

Re: Setting classpath

Posted by Peter Donald <do...@apache.org>.
At 11:45  24/12/00 +0100, Nico Seessle wrote:
>> And, I've discovered, when you set the classpath for the junit task, you
>> have to add both optional.jar and ant.jar to the classpath (at least you
>> do if you have "fork" set).
>
>What are you testing? And what is Ant's reaction if you don't include these
>two jar's in the classpath? (ClassNotFoundException? With what class?)

the problem is that the ant task and the junit.jar have to be loaded from
same classloader (actually the ant junit task has to be able to access all
the junit classes but can be in a different classloader but as ant is
loaded by primordial classloader then they both have to be in primordial ;/


>
>> Is there anyway to refer to the classpath that ant's VM was invoked
>> with?
>You can refer to it using java-properties, but I don't think you can use
>this to set up a classpath (but I have not tried it :-) )
>
>Nico
>
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Re: Setting classpath

Posted by Nico Seessle <Ni...@epost.de>.
----- Original Message -----
From: "David Corbin" <dc...@machturtle.com>
To: <an...@jakarta.apache.org>
Sent: Sunday, December 24, 2000 2:32 AM
Subject: Re: Setting classpath


> And, I've discovered, when you set the classpath for the junit task, you
> have to add both optional.jar and ant.jar to the classpath (at least you
> do if you have "fork" set).

What are you testing? And what is Ant's reaction if you don't include these
two jar's in the classpath? (ClassNotFoundException? With what class?)

> Is there anyway to refer to the classpath that ant's VM was invoked
> with?
You can refer to it using java-properties, but I don't think you can use
this to set up a classpath (but I have not tried it :-) )

Nico


Re: Setting classpath

Posted by David Corbin <dc...@machturtle.com>.
Sylvain Rey wrote:
> 
> > Oh yeah.  One more thing.  I seem to recall that the junit task won't
> > work if Junit is not on your classpath before you launch ant.  It's been
> > a week since I was dealing with this problem, so I could have it wrong,
> > but that's what it seemed like.
> 
> I had the same problem with JUnit. As I didn't want to have any classpath
> set outside from ant, I had to put junit.jar into ant/lib/ directory. This
> works for me but maybe there is a more smarter, correct way of doing this.
> Anyone ?
> 
> Sylvain

And, I've discovered, when you set the classpath for the junit task, you
have to add both optional.jar and ant.jar to the classpath (at least you
do if you have "fork" set).

Is there anyway to refer to the classpath that ant's VM was invoked
with?
-- 
David Corbin 		
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@machturtle.com

RE: Setting classpath

Posted by Sylvain Rey <ra...@bluedot.com>.
> Oh yeah.  One more thing.  I seem to recall that the junit task won't
> work if Junit is not on your classpath before you launch ant.  It's been
> a week since I was dealing with this problem, so I could have it wrong,
> but that's what it seemed like.

I had the same problem with JUnit. As I didn't want to have any classpath
set outside from ant, I had to put junit.jar into ant/lib/ directory. This
works for me but maybe there is a more smarter, correct way of doing this.
Anyone ?

Sylvain


Re: Setting classpath

Posted by David Corbin <dc...@machturtle.com>.
Oh yeah.  One more thing.  I seem to recall that the junit task won't
work if Junit is not on your classpath before you launch ant.  It's been
a week since I was dealing with this problem, so I could have it wrong,
but that's what it seemed like.

Nico Seessle wrote:
> 
> ----- Original Message -----
> From: "David Corbin" <dc...@machturtle.com>
> To: "Ant User" <an...@jakarta.apache.org>
> Sent: Saturday, December 23, 2000 10:22 PM
> Subject: Setting classpath
> 
> > Are there any plans to allow Ant to "set the classpath" for particular
> > tasks?  I find it extremely annoying to have to set the classpath
> > outside of ant.
> 
> Which version of Ant and which tasks? You can set a classpath for several
> tasks (i.e. javac, junit) inside your build.xml in Ant 1.2.
> 
> Nico

-- 
David Corbin 		
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@machturtle.com

Re: Setting classpath

Posted by David Corbin <dc...@machturtle.com>.
Nico Seessle wrote:
> 
> ----- Original Message -----
> From: "David Corbin" <dc...@machturtle.com>
> To: "Ant User" <an...@jakarta.apache.org>
> Sent: Saturday, December 23, 2000 10:22 PM
> Subject: Setting classpath
> 
> > Are there any plans to allow Ant to "set the classpath" for particular
> > tasks?  I find it extremely annoying to have to set the classpath
> > outside of ant.
> 
> Which version of Ant and which tasks? You can set a classpath for several
> tasks (i.e. javac, junit) inside your build.xml in Ant 1.2.
> 
> Nico

I'm using 1.2.  It seems to be I had problems setting it for junit.  Why
can't there be a common way to set it for all tasks?
-- 
David Corbin 		
Mach Turtle Technologies, Inc.
http://www.machturtle.com
dcorbin@machturtle.com

Re: Setting classpath

Posted by Nico Seessle <Ni...@epost.de>.
----- Original Message -----
From: "David Corbin" <dc...@machturtle.com>
To: "Ant User" <an...@jakarta.apache.org>
Sent: Saturday, December 23, 2000 10:22 PM
Subject: Setting classpath


> Are there any plans to allow Ant to "set the classpath" for particular
> tasks?  I find it extremely annoying to have to set the classpath
> outside of ant.

Which version of Ant and which tasks? You can set a classpath for several
tasks (i.e. javac, junit) inside your build.xml in Ant 1.2.

Nico



Re: Setting classpath

Posted by Peter Donald <do...@apache.org>.
At 02:42  2/1/01 -0800, James Duncan Davidson wrote:
>Probably pretty close to what I was thinking. Let me cast what I was
>thinking a bit differently and see where we are:

I agree 100% except I used different names ;)

>    3) any classpath info given in the task definition, if we
>       decide to support this
>    4) any potential classpath info given in the task itself, if
>       we decide to support this

I am not sure if we need to have per-task cp because if they need different
cp then shouldn't they be separate .tsks ? One thing I would like to see is
manifest ebntries such as 

Ant-Classpath: ${java.home}/lib/tools.jar ${ant.home}/lib/jaxp.jar

Where variables are interpreted in manifest at load time. Then we can throw
away most (if not all) issues I can think of. Thoughts ?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Re: Setting classpath

Posted by James Duncan Davidson <du...@x180.net>.
On 1/2/01 5:18 AM, "Peter Donald" <do...@apache.org> wrote:

> Agreed - what do you think of a hierarchy of classloaders such that
> 
> system <-- client task api (CTA)     <-- Task Archive + dependencies
> 
> so for CTA we would have the task interface/classes + support classes (like
> pattern/patterset, fileset, mappers etc). Each .tsk jar would have a
> separate classloader that loads task + dependent jars. SO if we have
> foo.tsk that has tasks that rely on bar.jar then we add the line
> "ClassLoader: bar.jar" to the manifest of foo.tsk and the classloader takes
> care of it.
> 
> We would also have the hierarchy
> 
> system <-- client task api (CTA)     <-- Ant Runtime engine
> 
> where the runtime engine included the execution engine + any other relevent
> files that are not included in CTA.

Probably pretty close to what I was thinking. Let me cast what I was
thinking a bit differently and see where we are:

                    System Classloader
            (rt.jar, lib/ext/*.jar, $CLASSPATH)
        (iow, the way we get it when Ant is started)
                            |
                            |
                  Ant Primary Classloader
                    (system + ant.jar)
                            |
                            |
        +-------------------+-------------------+
        |                                       |
Ant Utility Classloader           Task Runtime Classloaders
  (Primary ant + xml          (Primary ant loader + possible depends)
   parsing jars)

Where the possible depends in the Task Runtime Classloader space would be:

    1) the jar that the task was loaded out, if any
    2) the dependancies declared by that jar
    3) any classpath info given in the task definition, if we
       decide to support this
    4) any potential classpath info given in the task itself, if
       we decide to support this

Or something like that.

Ant itself would run in the primary classloader calling into the utility
classloader only to build the workspace/module/project tree up from the raw
XML. Note that a quick and dirty 3-4 class mini-parser that only knew how to
digest ant build files would nuke the need for that.

It kinda is a little scary talking about such classloader games as they can
be tricky things, but it'll be necessary to do this to implement what needs
to be implemented.

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()


Re: Setting classpath

Posted by Peter Donald <do...@apache.org>.
At 03:15  31/12/00 -0800, James Duncan Davidson wrote:
>(moved to -dev as this is more a futures "dev" discussion in this follow-up)
>
>On 12/29/00 3:05 AM, "Peter Donald" <do...@apache.org> wrote:
>
>> Hopefully in Ant2.0 you will be able to add the attribute
>> ant:classpath="..." and it will automagically run it via a new classloader.
>> It is something I would find extremely useful thou it is still up to
>> discussion thou ...
>> Cheers,
>
>Actually, all tasks should run in a classloader. My gut feeling right now is
>that they should get the system classpath (what was there before Ant ran) +
>the classpath needed to load the task (usually a .jar). This does assume
>that Ant takes care of all of it's dependencies via it's own custom class
>loader which allows the user to leave their classpath as free or ugly as
>they like it.
>
>The only thing more needed is additional classpath info which would be
>appended to the system classpath in the task's classloader.
>
>Note that I'm *not* for ignoring the system classloader space. Whatever
>users put into their $CLASSPATH env var or is in their /lib/ext, they should
>be able to live with. However, I completely buy into the notion that users
>shouldn't have things go freaky because Ant itself is relying on a xml
>parsing library or such.


Agreed - what do you think of a hierarchy of classloaders such that

system <-- client task api (CTA)     <-- Task Archive + dependencies

so for CTA we would have the task interface/classes + support classes (like
pattern/patterset, fileset, mappers etc). Each .tsk jar would have a
separate classloader that loads task + dependent jars. SO if we have
foo.tsk that has tasks that rely on bar.jar then we add the line
"ClassLoader: bar.jar" to the manifest of foo.tsk and the classloader takes
care of it.

We would also have the hierarchy

system <-- client task api (CTA)     <-- Ant Runtime engine

where the runtime engine included the execution engine + any other relevent
files that are not included in CTA.

Like/Dislike ?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Re: Setting classpath

Posted by James Duncan Davidson <du...@x180.net>.
(moved to -dev as this is more a futures "dev" discussion in this follow-up)

On 12/29/00 3:05 AM, "Peter Donald" <do...@apache.org> wrote:

> Hopefully in Ant2.0 you will be able to add the attribute
> ant:classpath="..." and it will automagically run it via a new classloader.
> It is something I would find extremely useful thou it is still up to
> discussion thou ...
> Cheers,

Actually, all tasks should run in a classloader. My gut feeling right now is
that they should get the system classpath (what was there before Ant ran) +
the classpath needed to load the task (usually a .jar). This does assume
that Ant takes care of all of it's dependencies via it's own custom class
loader which allows the user to leave their classpath as free or ugly as
they like it.

The only thing more needed is additional classpath info which would be
appended to the system classpath in the task's classloader.

Note that I'm *not* for ignoring the system classloader space. Whatever
users put into their $CLASSPATH env var or is in their /lib/ext, they should
be able to live with. However, I completely buy into the notion that users
shouldn't have things go freaky because Ant itself is relying on a xml
parsing library or such.

.duncan

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()


Re: Setting classpath

Posted by Peter Donald <do...@apache.org>.
At 04:22  23/12/00 -0500, David Corbin wrote:
>Are there any plans to allow Ant to "set the classpath" for particular
>tasks?  I find it extremely annoying to have to set the classpath
>outside of ant.

Hopefully in Ant2.0 you will be able to add the attribute
ant:classpath="..." and it will automagically run it via a new classloader.
It is something I would find extremely useful thou it is still up to
discussion thou ... 
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Re: Setting classpath

Posted by Peter Donald <do...@apache.org>.
At 04:22  23/12/00 -0500, David Corbin wrote:
>Are there any plans to allow Ant to "set the classpath" for particular
>tasks?  I find it extremely annoying to have to set the classpath
>outside of ant.

Hopefully in Ant2.0 you will be able to add the attribute
ant:classpath="..." and it will automagically run it via a new classloader.
It is something I would find extremely useful thou it is still up to
discussion thou ... 
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*