ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <dun...@x180.net>
Subject Re: Setting classpath
Date Tue, 02 Jan 2001 22:42:53 GMT
On 1/2/01 5:18 AM, "Peter Donald" <donaldp@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()


Mime
View raw message