ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <>
Subject Re: cvs commit: jakarta-ant/proposal/myrmidon/src/java/org/apache/myrmidon/components/builder ant1convert.xsl
Date Wed, 20 Mar 2002 03:42:15 GMT
On Mon, 18 Mar 2002 23:11, Adam Murdoch wrote:
> > -----Original Message-----
> > From: Darrell DeBoer []
> > Sent: Monday, 18 March 2002 10:32 PM
> > To: Ant Developers List
> > Subject: Re: cvs commit:
> > jakarta-ant/proposal/myrmidon/src/java/org/apache/myrmidon/components/bu
> > ilder ant1convert.xsl
> >
> >
> >
> >
> > Additionally, I'd like to come up with a generic way to plug in new Ant1
> > tasks without needing to taskdef them. I'm not sure if this would involve
> > making ant1compat.atl available as an extension, so that an
> > antlib containing
> > Ant1 tasks could declare a dependency on this. I'm not all that
> > familiar with
> > extensions, so I'll have to play around with this a bit.
> This won't work particularly well as things currently stand, because an
> antlib and its extensions are loaded together in the same classloader. 
> Ant1compat.atl is an antlib itself, so it won't be loaded in the common
> classloader.  Net result is that you'll get a copy of ant1compat.atl loaded
> by the classloader for each antlib, and so the tasks won't be able to
> interact across antlibs.
> However, we should be able to make ant1compat.atl a .jar now.  Then you
> should be able to simply drop in an antlib and have it work, regardless of
> whether it contains ant 1 or ant 2 tasks.
> Not sure how the dependency on tools.jar and an XML parser will fit in
> there.  An extension would probably work for them.

I quickly tried this out - the tools.jar extension didn't seem to be loaded 
when I renamed to ant1compat.jar. Anyhow, we probably need a more general 
solution to the problem of adding antlibs which depend on other antlibs.  An 
example would be if you extended a antlib with a new different task, and 
wanted to be able to share datatype references between the new and existing 
tasks. (You don't want to always force the original antlib to be a .jar, and 
reside in the top-level classloader).

I don't think he way extensions currently work will work, because the classes 
will be loaded separately for each antlib, so instances couldn't be shared. 
It seems that we need a way to declare that Antlib-A "depends" on antlib-B, 
so that antlib-A could be loaded in a ClassLoader that was a child of the 
antlib-B's classLoader.

More stuff to do, I guess.


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

View raw message