On Sat, 12 Dec 2009 13:03:45 +0100, Jean-Louis Boudart
<jeanlouis.boud...@gmail.com> wrote:
> How about:
>
> <target-inteface name="foo"/>
> <target name="bar" implements="foo"/>
>
> /me run and hides!
>
> 2009/12/12 Nicolas Lalevée <nicolas.lale...@hibnet.org>
>
>> On Fri, 11 Dec 2009 11:51:30 -0600, Dominique Devienne
>> <ddevie...@gmail.com> wrote:
>> > On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin
<xavier.ha...@gmail.com>
>> > wrote:
>> >> 2009/12/10 Stefan Bodewig <bode...@apache.org>
>> >>> and would do away with any notion of target composition people way
>> >>> expect from the name target-*group*.
>> >> I also think the name target-group is confusing for something that
>> >> doesn't
>> >> provide any composition. [...] What do you think this:
>> >> <target name="foo" dependencies="open"/>
>> >> <target name="bar" join-depends="foo"/>
>> >
>> > Like in a SQL join you mean? ;)
>> >
>> >> But I'm not good at finding names, so maybe I should just go back to
>> >> my
>> >> work :-)
>> >
>> > Frankly I think the Maven terminology of a "goal" is appropriate
here.
>> > The fact that a goal is implemented as a target that has no tasks is
>> > an impl detail. I think it easier that a goal is a higher level
>> > abstraction that the target, and that target can choose to
participate
>> > into one and only one goal. Whether goals themselves should only
>> > depend on goals might be a good idea. Goals would define the
"abstract
>> > interface" to the build system and logic, and targets become its
>> > implementation. As I wrote, a target can belong to only a single
goal,
>> > but can depend on targets or goals, as long as the DAG is acyclic.
>>
>> I think that "abstract interface" target and "implementation" target
>> seems
>> to fit very well into my use case I presented earlier. It was about a
>> build
>> script expecting some target implementation to be run before some
other;
>> expecting "build-jar", "build-flex" to be run before "ivy-install". And
>> then the abstract target is "dist".
>>
>> Then about the term "goal", I don't find it self explaining, but if in
>> Maven there is the same exact notion, I am good with not spreading new
>> terms for the same ideas. On the other hand if there would be non
trivial
>> difference, we shouldn't choose "goal". I cannot say thought, I don't
>> know
>> Maven enought.
I have found the interesting part in the Maven book [1]. So in Maven,
there are some defined "lifecycles". A lifecycle defines a sequence of
"phases". And there are "goals" that get attached to "phases". It doesn't
seems there is a particular build graph, goals doesn't seem to declare any
particular dependencies. On the other hand the phases are ordered in the
lifecycle.
The end user usually launch "phases" ('install'), but he can also launch
goals ('jar:jar': if nothing have been explicitely build, then that jar
will be empty, no dependency on some 'compile').
So as far as I understand Ant targets could be then compared to maven
goals for their implementation part, and maven phases for their
dependencies among them. Target groups in the current implementation are
then just phases (and if I remember correctly I was named phases when they
were initially suggested).
Finally as targets already decribe the build graph, I see no real need to
add another element for that, further more knowing that I am not sure we
have a clear view of what it should actually be. And it might be confusing
for build writers how and when to use target groups rather than simple
targets. I think we should focus on the real feature which is needed here:
be able to _append/hook_ some nodes to an "external" build graph without
_modifying_ it. Then I would be quite pragmatic and suggest to just add
this feature to the actual Ant model, here the targets.
In EasyAnt there is already this notion of phase. But I see no real
conflict with not supporting target groups in Ant. EasyAnt could just
implement phases as targets, it would be "just" an implementation detail.
Nicolas
[1] http://www.sonatype.com/books/maven-book/reference/lifecycle.html
>>
>> Nicolas
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
