Dominique, >> If the project you checkout includes its own Ant extensions
I does not and I also believe it should not. I believe it's a rather good rule that a source repository contains sources and not binaries. Perhaps I should also mention that I'm not talking here about one or two projects. It's more a matter of hundreds or even thousands. >> Using -lib is just as effective as putting the jars in >> $ANT_HOME/lib I believe [..] >> [..] >> Then you only need a little wrapper build.bat/.sh [..] The problem starts already with the fact that you need to maintain two scripts (Windows and Unix). Then you need to download somehow. You can't assume that wget is around. So my script generates/contains a Ant script 'fetch.xml' which I would need to call to my plugins in place (using get task to download). I optimize this script to call Ant only in case something is missing.... Then you have the problem that you just add another complexity level, i.e. the script. If something is going wrong you firstly start to blame this script .. Finally there's the scenario where the build script is implemented in terms of a framework sitting on top of Ant. This frameworks builds the project, the developer does not need to care about the details. If this framework requires a new dependency, then I would need to change each "build.bat/.sh" script around. I could also optimize this by letting my down- loader fetch a list of artefacts to be downloaded. Then I only need to change this list on a central server ... I went a bit a different path in my framework case. I just created one big fat binary containing all those extension jars. So I just need to ask our users to update a single jar once in a while. It works although it's another ugly hack. I'm not a fan of Maven, but this automatic "plugin" download feature is really a good thing! >> Sure, auto-download of dependencies would be nice, and with Ivy >> part of the Ant family, it may come sooner rather than later, [..] I'm in favor of "sooner" :-) Of course, if I'm the only one missing "auto-download" then it doesn't make sense to ask for it. Regards, Wolfgang Häfelinger Research & Architecture | Dir. 2.7.0.2 European Patent Office Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands Tel. +31 (0)70 340 4931 [EMAIL PROTECTED] http://www.epo.org "Dominique Devienne" <[EMAIL PROTECTED]> 14-11-2007 16:18 Please respond to "Ant Developers List" <dev@ant.apache.org> To "Ant Developers List" <dev@ant.apache.org> cc Subject Re: ApacheCon Presentation On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote: > * Simple fix...place all third-party jars in $ANT_HOME/lib > > Honestly, putting something into Ant's lib directory is really ugly and all > those alternatives ($HOME/.ant etc) do not solve the overall problem. If the project you checkout includes its own Ant extensions, and you want to use a stock Ant release, you still have the option of using the -lib command line switch to tell the Ant launcher to use your custom libs. Using -lib is just as effective as putting the jars in $ANT_HOME/lib I believe. Then you only need a little wrapper build.bat/.sh script (checked in) to launch Ant properly configured for the projects. Sure, auto-download of dependencies would be nice, and with Ivy part of the Ant family, it may come sooner rather than later, but in the mean time, -lib is a very effective and easy way to work around your issue it sounds like. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]