ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: target-group committed
Date Tue, 25 Nov 2008 20:26:29 GMT
I am in the same boat as Stefan. I also don't understand yet why 
target-groups are not just targets to the person running Ant.

What you appear to be arguing here is that there should be two levels to 
Ant targets. But why just two? Why not three or four or five?

I've written build systems this way in the past. Here is an example:

Level 1 = top level targets that span multiple modules, depend on level 
2 targets and add timestamps to logs. Description defined.
Level 2 = top level targets for a specific module, depend on level 3 
targets and add timestamps to logs. Description defined.
Level 3 =  more granular targets that encapsulate reusable sets of 
behaviour, depend on level 3 and 4 targets. No description.
Level 4 = fine-grained targets, depend only on initialization targets. 
Used when you know exactly the state of your environment and want to do 
something specific with no time wasted, like in a developer sandbox. 
Description defined.
Level 5 = initialization targets. No description.

I used naming conventions for targets to differentiate the levels. For 
example, level 4 targets all ended with "-only" to indicate there were 
few dependencies being run. There are other solutions, though. Perhaps 
targets could have a "level" attribute and -projecthelp could take an 
optional numeric parameter to indicate the level you want to see. 
Someone building a module could run "ant -p2" to find out which targets 
were available to them. A developer could run "ant -p4". To make things 
more user-friendly, EasyAnt could define a standard set of levels and 
name them rather than using numbers.

That is just one idea. Regardless, I think a more general solution would 
be better than treating target-groups in a special way, or even worse by 
adding target-parts to the mix. But then again, I may be missing something.

Jean-Louis BOUDART wrote:
> I agree with Xavier a target-group is something at a higher level than a
> target.
> I think that the key feature of target-group is dependency injection but as
> Xavier says "if thread-group is the only way to have target dependency
> injection, then people may use it only for that, and complain about the
> distinction in project help".
> The fact is target-group is not only a way to have dependency management,
> but a "new way" to think your build-script.
> I guess for us target-group is useful to make build modules easily reusable
> in a standard build (with standard target-group), without requiring any
> specific orchestration.
> This means target-group allow you to have a kind of "generic target", that's
> why in EasyAnt we want to have separated help for generic targets
> (target-group) and specific target (normal target).
> In addition, as we use target-group to have more "genericity" we doesn't
> want to have prefix on those "generic" targets.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message