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 Wed, 26 Nov 2008 20:06:31 GMT
Right. I see a "part-of" relationship of arbitrary depth as being best 
implemented using a Composite design pattern. A target-group is a 
composite for targets but is itself also a target.

The level idea was only an example off the top of my head, but in 
thinking about it you are right that numeric levels would be a bad 
choice. The reason I thought of using numbers was so that the lower 
layers would implicitly contain the higher ones but it really is obscure 
and arbitrary from the users perspective.

Another solution would be to create different "interfaces" onto the 
build file for different types of users running Ant. A "visibility" 
attribute on targets could be set to the names of interfaces that could 
be requested and would list that target if you ran Ant with the 
interface specified, e.g. "-p=developer". You would need some new tag if 
you wanted "extends" behaviour, though.

Yet another solution would be to add an attribute to allow stripping 
descriptions from imported and included targets. Then the user could 
write different top-level build files for different classes of users, 
each choosing which imported targets got to keep their descriptions.

Or you could just live with the verbosity of the target list, like I 
did, and use naming conventions in EasyAnt. I'm sure there are many 
other ways to address the issue.

Gilles Scokart wrote:
> 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.
> Gilles
> 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:

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

View raw message