ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: My itches for 1.6
Date Mon, 15 Jul 2002 23:40:09 GMT
At 04:30 PM 7/15/2002 -0700, you wrote:
>On Tue, 16 Jul 2002, Adam Murdoch wrote:
> > > 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.
>+1 ( not my itch at this moment, but I agree is quite usefull ). I was
>hoping antlib is on someone's itch-list for 1.6 :-)
>The manifest is quite standard and hopefully will be used more in
>the future. Maybe we can also enhance <jar> to better support the
>generation ( if it is not already done :-).

Look at optional/extension/** stuff in ant1.5. It supports generation of 
manifest from sets of dependencies. It also supports declaring extension, 
extensionset etc datatypes and a few other nifty things. It has the start 
of support for retrieval of librarys for extensions (ie you can get 
extension from a URL or from a file or as result of ant build).

 > 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
> > care of this, the tasks and datatypes don't know or care.
>Still confused - how is that different from creating a LibraryPath type
>that extends Path and has the behavior you want ?

See typed elements on

Essentially it allows users to install their own implementation of types 
(ie path elements or whatever) without having to extend tasks. Large chunks 
of ant1 code sucks because of inappropriate extension of tasks - especially 
when you have incompatible extensions. ie HP extended the ejbc tasks for 
their own container as did other J2EE vendors.

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

View raw message