ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolfgang Häfelinger <whaefelin...@epo.org>
Subject Re: ApacheCon Presentation
Date Wed, 14 Nov 2007 16:12:49 GMT
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
whaefelinger@epo.org
http://www.epo.org




"Dominique Devienne" <ddevienne@gmail.com> 
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 <whaefelinger@epo.org> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message