I'm not sure I followed your suggestion. As far as allowing a way to automagically include stuff without adding it to the base installation, Antoine added the -lib option and Conor extended it to pull all jars from directories on (looks like) a path-style argument specified with that option (as well as including the directories themselves). So now I can store lots of antlib.xml files right on the filesystem, say under $HOME/.ant/lib in multiple package structures, set ANT_ARGS to include "-lib $HOME/.ant/lib" and voila! I can now modify commonly-used antlibs all I want.
Now we can conceive of auto-installers that modify $HOME/.antrc to append -lib options to ANT_ARGS to point to 3rd-party stuff... since windows systems are less likely to use shared Ant installations, Un*x is the most useful place for this stuff. -Matt --- Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: > > Hi, I have been giving some thought on ways to solve > this nagging > issue of needing to put antlib jars on the lib > directory. > > We hear over and over people wanting to keep their > third party > libraries out of -lib because they are only for an > specific project. > > As I see it, our road block has been how to tell in > succinct way in the > buildfile that when loading the namespace > "antlib:foo.bar" you should > use this or that classpath or classloader. > > A simple solution could be to achieve this by name > association: > > - When ANT tries to find and load the resource for > "antlib:foo.bar" > it will first look for a reference named "foo.bar" > representing > a classloader (or classpath?). If an object of the > correct type is > found, then this classloader will be user for > resolving and loadding > the antlib, otherwise the default classloader will > be use, as it is > today. > > So with this in place, one could write things like: > > <project name="x" xmlns:lib="antlib:foo.bar"> > > <classpath id="foo.bar">.....</classpath> > > <lib:mytask ..../> <!-- The antlib loaded using > the classloader for > "foo.bar" --> > > </project> > > Before jumping on a code proposal, does this sound a > the right or good > solution? Does this cover enough of the use cases? > > Let me know what you people think. > > Jose Aberto > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
