ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <>
Subject Re: target-group committed
Date Wed, 26 Nov 2008 08:00:33 GMT
I was asking to myself the same question : why only 2 levels?
I think you are right, we don't need different type of targets, what
we should have is a new type of relationship between targets : the
PartOf relationship that allow to plug a 'lower' level target INTO an
other target.

But for the idea of numerical level, I think it is going too far into
a strict layer decomposition.  This might be too restrictive.  Having
a PartOf relationship allow to do strict layering elegantly, but there
might be other usage to partOf.
If the only benefits of a numerical layer is to hava a -p1 .. -pn
options, then I think the benfit is too limited.


2008/11/25 Bruce Atherton <>:
> 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:

Gilles Scokart

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

View raw message