ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <>
Subject Re: My itches for 1.6
Date Mon, 15 Jul 2002 23:16:24 GMT
On Tue, 16 Jul 2002 10:19, wrote:
> 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.

Indeed.  There's also the question of how the dependencies get resolved (and 
how to make that extensible).

I'd like to look at moving some of the antlib stuff across from myrmidon.  A 
decent classloader model would make that much simpler.  And if we're happy 
with using the manifest to define dependencies, then I could look at moving 
across some of the resolution stuff.

> 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 ).

I should have explained this a little more.  That's what my 'polymorphic 
types' comment was all about.  We don't actually change Path to add new path 
implementations.  We simply register <library-path> as a new path 
implementation (using <typedef> or by importing an antlib).  Then a 
<library-path> can be used anywhere that a <path> can.  The runtime takes 
care of this, the tasks and datatypes don't know or care.  

We have a bunch of path implementations, eg one that returns the ant runtime 
(so that you can use it to compile tasks - this replaces <javac>'s dodgy 
includeAntruntime attribute), one that returns a JVM's runtime (so that you 
can cross compile), one that filters another path using selectors, and so on.  
And it's really easy to add your own custom ones: just whack them in an 

> > > - 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.

Yep, getting there incrementally is a good idea.  Hopefully in 1.6 we'll have 
some kind of antlibs happening, in which case we could turn optional.jar into 
a giant antlib, and chop it up over time.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message