ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: My itches for 1.6
Date Mon, 15 Jul 2002 23:30:08 GMT
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 :-).

It will simplify the hierarchy - all we need is to scan all libs in
ant/lib/??? ( some scheme may be needed for system-installed jars )
and in some <paths> defined by the user in build.xml, then construct
a classloader based on those.


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

Still confused - how is that different from creating a LibraryPath type
that extends Path and has the behavior you want ? 

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

+1.

Costin


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


Mime
View raw message