You're right.
Initially in EasyAnt we wanted to find a way to define lifecycles. A
lifecycle is composed by a sequence of generic steps (what we've called
"phase").
Then we could play with additional script (plugins) that can be bind to a
phase.
Again the idea was to make genericity in our build scripts.
So suppose we have a target that does the java-compilation (bind to compile
phase), another one that does the jar-packaging (bind to package phase)
etc...
Now suppose we want to build a webapp the only thing that will differ with
my previous exemple is the target that package the war (which can be bind to
package phase).
As a end user we will still have the common lifecycle with all our steps
(phase) like compile, package etc... in any context (standar java
application, webapp etc...)
Since our use case was really similar with maven phases we decided to use
the same name.
Now i think it can be limitting to integrate it in ant with that
name(phase), that's why when this feature was introduced in ant's trunk,
someone suggested to call it "target-group".
By the way there is still a main difference between a target-group and a
phase.
A phase is never prefixed whereas a target-group can be prefixed depending
on how you <import>/<include> it.
Again if we consider target-group is JUST a way to have target dependency
injection, this doesn't make sense.
In opposite if we consider that target-groups are toplevel target(to define
a lifecycle for exemple), does't it make sens to have prefix on
target-group?
Example (using current HEAD revision):
Suppose you want to have a generic task called report
a.xml
<project name="A">
<target name="javadoc" target-group="report" description="generate javadoc">
<echo>javadoc</echo>
</target>
...
</project>
b.xml
<project name="B">
<target name="junitreport" target-group="report" description="generate junit
report">
<echo>junitreport</echo>
</target>
...
</project>
c.xml
<project name="C">
<target name="emma-report" description="generate emma report"
target-group="report">
<echo> emma report</echo>
</target>
...
</project>
phases.xml (containing our lifecycle)
<project name="phases">
<target-group name="report" description="generate all report for your
project" />
</project>
build.xml
<project name="generic-build">
<import file="phase.xml"/>
<include file="a.xml" as="javadoc"/>
<include file="b.xml" as="junit"/>
<include file="c.xml" as="emma"/>
</project>
If you try to use "ant report" :
you have this message "can't add target javadoc.javadoc to target-group
javadoc.report because the target-group is unknown."
Using phase (a target-group never prefixed), it is possible in a buildscript
to assign a target to a phase which is not declared in the current build
script. It makes the buildscript dependent on the caller to declare the
phase prior to the use call, and as such becomes a requirement of the
buildscript.
Considering that this was a use case really related to easyant, we've made
our own implementation of phase inspired by target-group current code base.
This means we have our own ProjectHelper so we will not be really affected
by any change the naming of target-group.
Hope this will help the discution.
Cheers,
Le 16 décembre 2009 14:12, Nicolas Lalevée <nicolas.lale...@hibnet.org> a
écrit :
> 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
>
>
--
Jean Louis Boudart
Independent consultant
Project Lead http://www.easyant.org
