As I said, I am not against using -lib (or some other environment magic) my only point is that I would also think that having a way to specify this things in the project file itself (and keeping it as succinct as possible) would be good.
In particular when you have different projects each with its own set of third party libraries. Jose Alberto > -----Original Message----- > From: didge [mailto:[EMAIL PROTECTED] > Sent: 03 April 2004 00:02 > To: Ant Developers List > Subject: RE: antlib and classloaders > > > So what's to say that we can't build up an ANTLIB_PATH just > like we build up CLASSPATHs using <classpath>? > > didge > > > -----Original Message----- > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > Sent: Friday, April 02, 2004 2:46 AM > > To: Ant Developers List; [EMAIL PROTECTED] > > Subject: RE: antlib and classloaders > > > > > > The only issue I have with your suggestions is the fact that they > > require the user to express dependencies outside the project itself. > > > > This may be fine for many, but if you have to deal with multiple > > projects that require different sets of dependencies, it > would be nice > > if one could express this in the buildfile itself were it > can be more > > easily maintained. > > > > The alternative today that most of us have to use is to > create our own > > build.{sh,cmd,bat} and place the correct -lib args in the > script. But > > then you may have to maintain that script too during the > life of the > > project. > > > > My aim is to try to provide an in-buildfile alternative. > > > > Jose Alberto > > > > > -----Original Message----- > > > From: didge [mailto:[EMAIL PROTECTED] > > > Sent: 02 April 2004 01:16 > > > To: Ant Developers List > > > Subject: RE: antlib and classloaders > > > > > > > > > How about just supporting an equivalent of an LD_LIBRARY_PATH for > > > antlibs, called ANTLIB_PATH or some such? > > > > > > didge > > > > > > > -----Original Message----- > > > > From: Matt Benson [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, April 01, 2004 1:58 PM > > > > To: Ant Developers List > > > > Subject: Re: antlib and classloaders > > > > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - > > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
