Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Date: Mon, 15 Jul 2002 15:19:28 -0700 (PDT)
From: costinm@covalent.net
To: Ant Developers List <ant-dev@jakarta.apache.org>
Subject: Re: My itches for 1.6
In-Reply-To: <200207160949.21145.adammurdoch@apache.org>
Message-ID: 
 <Pine.LNX.4.44.0207151503440.12657-100000@costinm.sfo.covalent.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 16 Jul 2002, Adam Murdoch wrote:

> > - the webapp class loader that can use Manifest entries to find
> > and resolve dependencies, as well as allow 'webapps' to override some
> > classes ( as required by the servlet2.3 spec - but that can be used
> > in ant as well).
> 
> This is what myrmidon does.  It's a quite powerful approach, since you declare 
> the dependencies in logical rather than physical terms. ie you declare 'I 
> need junit' or 'I need junit version 3.7', rather than 'I need junit.jar'.  
> This gives the container heaps of flexibility in how it actually finds the 
> extensions (ie dependencies) that a jar needs.

The question is if we should do it in 1.6 and how. We can extend the 
AntClassLoader with code from tomcat or myrmidon, or just use one of those
class loaders. That's not very difficult. 

I personally don't see this as a very big priority ( or itch ), but I'm
+1 if someone wants to do it in 1.6.

I'm not very convinced about the use in Path - but I agree it would be 
nice to expose the manifest dependency information of a jar ( i.e. I
wouldn't make Path too complex, but use some separate types/tasks ).


> > - a hierarchy that is more flexible than 'all jars in CLASSPATH' -
> > I think most problems can be solved by just 3 layers ( core,
> > optional + global taskdefs, taskdefs with specific loader ). If
> > needed we can also use a separate loader for 'server' ( in our
> > case ant ). And in time we can enhance it further.
> 
> The classloader heirarchy in myrmidon looks something like the tomcat one:
> 
>          Bootstrap
> 
>           System
> 
>           Common
>          /      \
>      Myrmidon  Shared
>               /     \
>           antlib1 antlib2 ...
> 
> Each antlib is loaded in its own classloader.  We've split Optional.jar and 
> most of the core tasks, into several antlibs.

I think for 1.6 we should just move the optional.jar out of the 
CLASSPATH. Each taskdef can already have it's own loader, so we'll
have:

   System( i.e. CLASSPATH + ant/lib) = Ant 'core' + core tasks
     |
   Task loader = Optional.jar, all the jars that are required, tasks 
                 defined with taskdef without an explicit classpath
    /      \
 antlib1   antlib2 = taskdefs with explicit classpath.


In future (1.7?) we may have some of the ant impl classes in a separate
loader.

The main benefit of this scheme is that it requires the minimal pain on 
the users, it solves most of the problems, is reasonably simple. 
In addition, it avoids many ClassCast exceptions and similar problems.

However, if we add SAX2 we can also do something about spliting
optional.jar in 'libraries' with a namespace and separate loaders, 
and we can reproduce the hierarchy you describe using some explicit
tasks ( so users who need this flexibility can have it, but for
simple tasks we keep the model simple ).


Costin


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>