--- Colin Sampaleanu <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
