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]
