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 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 ?
See typed elements on
http://jakarta.apache.org/ant/myrmidon/configuring.html
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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
