You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <do...@apache.org> on 2001/01/02 14:18:35 UTC
Re: Setting classpath
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 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()