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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
