Well, I am glad this is having a strong debate. Let me first say where I am coming from with this issue and then some of my thoughts on this and others comments.
My main peeve currently is defaults.properties. To me it is an aberration now that we have antlibs. This file tries to load a whole load of tasks that at the end will not work because people do not have the supporting optional stuff. And it does not load the things that I do have. I want this done by the antlib mechanism itself which is already there. Now, to some of the comments: 1) How about collisions? Well, how about collisions between classes in the classpath? Is this really much different? Maybe, maybe not. How about loading a task that collides with one already defined in defaults.properties? What do we do in this case? Shall we react the same way? 2) Shall we keep control on what gets aoutoloaded? I would say yes! I disagree on having some global switch (option) instead I would propose something like -lib (no autoloading) and -autolib (do autoloading). With this in mind the things in the ANT distribution library will be loaded using the -autoload option and for other external libraries people can decide what should happen. 3) Have an antlib.xml in META-INF for autoloading. My only misgiving on doing it this way is the duplication of declarations. I do not like duplication. I would prefer providing something that just points to the package where the antlib.xml will be loaded when using name-spaces. So there is only one maintenance point. We could just use the java services mechanism or something very similar: We have a file META_INF/services/org.apache.ant.autoload (or something like that) that contains the packages where to look for antlib.xml files to load. That will make things reasonably simple, and all integrated. Comments, Jose Alberto > -----Original Message----- > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > Sent: 09 September 2005 22:57 > To: Ant Developers List > Subject: Re: Antlib autoloading (was Re: cvs commit: > ant/src/testcases/org/apache/tools/ant/taskdefs AntlibTest.java) > > On 9/9/05, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > > So, any ideas how this could be acomplished? > > Load all resources from META-INF/antlib.xml at startup and process > > them, I'd say. > > But doesn't that go against Ant's tradition to not have auto-magic > things, but instead spell things out explicitly, usually in the build > file? > > I'd rather we extend <typedef> to accept a <fileset> of AntLib jars to > load, possibly thru META-INF/antlib.xml, than auto-magically loading > all possible antlibs visible from the classpath. At least you can see > it and start looking at the jars it loads. > > How would you know looking at a build file where a task is coming from > otherwise? > > Also, for example, I have quite a few AntLibs which are in ant/lib, > and thus on Ant's classpath, but I don't use all of them in all my > builds. They're there because it's our official supercharged > production Ant distro, but loading all of them in builds that require > none or just a few is wasteful. > > I personnally want to stay in control of what gets loaded in each > build. I don't want to prevent others to do it if they fancy it, as > long as it's not forced on me. --DD > > PS: And BTW, Matt's point about conflict resolution is a good one. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
