ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <colin...@exis.com>
Subject Re: Ids from paths not propogated through antcalls unless path is top-level
Date Thu, 28 Feb 2002 15:33:42 GMT
Diane Holt wrote:
> --- Colin Sampaleanu <colinml1@exis.com> wrote:
>>Ok, but there's the rub. In my build files I have a number of targets 
>>which are simply there to set certain key properties or do some 
>>lightweight work. I very of do use
>>  ant A B C D
>>where A,B,C are only there to set things up, and D is the one the does 
>>the 'real' work.
>>
> Do you really want to have to specify the build order like that, on the
> command-line? Wouldn't it preferable to put together targets that do what
> you need them to, in the order you need them done?  Or maybe you could
> look into putting your config stuff into properties files?  Seems like you
> might want to reevaluate the way you currently have things set up.
> 
> Diane

The build is complicated enough that while most of the time I can do 
what I need with one target, it is simply unrealistic to create a 
specific target which encapsulates all the little variations I need. 
W/regards to setting properties, sure, I use property files, but for a 
one-time change it is a lot easier to specify it on the command line 
than go into a file, and easier to specify a property via a shortcut 
target than using the form -Dxxx=y, e.g. I prefer to type something like
   ant extra-tests remotehost clean dist run-tests
which tells it to do a dist build, then run all tests, while compiling 
in some extra test code, and using another host/port than the default 
localhost to deploy to. This example is just slightly contrived since I 
do in fact have one target that does a clean, a dist build, and then 
runs tests, but in fact it is reasonable since I have several modules 
comprising the whole thing, and given the fact that JDO is being used 
(which means classes have to be enhanced, and the schema optionally 
reset in the database or not, etc.), I rarely want to or need to build 
the whole thing.

What I am saying is that while I think it reasonable that the current 
behavior of
   ant A B C
resets the dependency stack for each target, where you are effectively 
stacking unrelated commands, an equally valid case can be made for the 
case where you are stacking related commands, so want to combine 
dependencies (to the extent that if B has some dependencies, and A has 
already done them, they shouldn't be done again).



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message