Re: Maybe we should open up "depends" for all targets [again]
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 / 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 javadoc ... b.xml junitreport ... c.xml emma report ... phases.xml (containing our lifecycle) build.xml 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 a écrit : > On Sat, 12 Dec 2009 13:03:45 +0100, Jean-Louis Boudart > wrote: > > How about: > > > > > > > > > > /me run and hides! > > > > 2009/12/12 Nicolas Lalevée > > > >> On Fri, 11 Dec 2009 11:51:30 -0600, Dominique Devienne > >> wrote: > >> > On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin > > >> > wrote: > >> >> 2009/12/10 Stefan Bodewig > >> >>> 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: > >> >> > >> >> > >> > > >> > 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
Re: Maybe we should open up "depends" for all targets [again]
On 2009-12-16, Nicolas Lalevée wrote: > 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. AFAIU EasyAnt uses a ProjectHelper of their own, so it is not really that affected by what we decide. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Maybe we should open up "depends" for all targets [again]
On Sat, 12 Dec 2009 13:03:45 +0100, Jean-Louis Boudart
wrote:
> How about:
>
>
>
>
> /me run and hides!
>
> 2009/12/12 Nicolas Lalevée
>
>> On Fri, 11 Dec 2009 11:51:30 -0600, Dominique Devienne
>> wrote:
>> > On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin
>> > wrote:
>> >> 2009/12/10 Stefan Bodewig
>> >>> 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:
>> >>
>> >>
>> >
>> > 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
Re: Maybe we should open up "depends" for all targets [again]
How about: /me run and hides! 2009/12/12 Nicolas Lalevée > On Fri, 11 Dec 2009 11:51:30 -0600, Dominique Devienne > wrote: > > On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin > > wrote: > >> 2009/12/10 Stefan Bodewig > >>> 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: > >> > >> > > > > 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. > > Nicolas > > > - > 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
Re: Maybe we should open up "depends" for all targets [again]
On Fri, 11 Dec 2009 11:51:30 -0600, Dominique Devienne wrote: > On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin > wrote: >> 2009/12/10 Stefan Bodewig >>> 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: >> >> > > 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. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Maybe we should open up "depends" for all targets [again]
Xavier Hanin wrote: 2009/12/10 Stefan Bodewig 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. Still I'm not sure dependencies="public" fits very well, it sounds like a visibility thing to me. And before-targets sounds like the before targets will be executed before the declaring target (just like depends actually). What do you think this: How about: Perhaps that suggests inheritance, so you could go with 'extend-depends' or 'dep-extend' or something. Alternately we could use: But I'm not good at finding names, so maybe I should just go back to my work :-) Xavier Stefan - 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
Re: Maybe we should open up "depends" for all targets [again]
On Fri, Dec 11, 2009 at 6:32 AM, Xavier Hanin wrote: > 2009/12/10 Stefan Bodewig >> 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: > > 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. My $0.02, I just can't resist when the discussion turns to finding good names! --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Maybe we should open up "depends" for all targets [again]
2009/12/10 Stefan Bodewig > On 2009-12-09, Nicolas Lalevée wrote: > [...] > > > > Now thinking loud, maybe a simple attribute on target like > > dependencies="public" would also fit ? > > Likely coupled with changing the current target-group name. > > Only thinking loudly as well we could turn > > > > > into > > > > > 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. Still I'm not sure dependencies="public" fits very well, it sounds like a visibility thing to me. And before-targets sounds like the before targets will be executed before the declaring target (just like depends actually). What do you think this: But I'm not good at finding names, so maybe I should just go back to my work :-) Xavier > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Xavier Hanin - 4SH France - http://www.4sh.fr/ BordeauxJUG creator & leader - http://www.bordeauxjug.org/ Apache Ivy Creator - http://ant.apache.org/ivy/
Re: Maybe we should open up "depends" for all targets [again]
On 2009-12-09, Nicolas Lalevée wrote: > Well, the title of this mail is referencing [1], The short summary: it was discussed whether target-groups should be allowed to contain tasks. I then mused whether we should do away with target-group completely and make target's depend attribute extensible just like the one of current target-group is. > I have a "build system" to maintain, shared between several different > kind of project, simple java ones, webapp ones, flex app ones, flex > lib ones, webservice ones, etc... All of these projects share the same > release process and dependency management (Ivy of course ;) ). So I > have a common-build.xml, a common-build-java.xml, a > common-build-webapp.xml, a common-build-flex, etc... > There is some sort of inheritance between those build scripts: > common-build-java.xml depends on common-build.xml, > common-build-webapp.xml depends on common-build.java, etc... I have a > "dist" target in common-build which expect things to be build before > being published with Ivy. Then in common-build-java I have targets to > build jars, and "dist" is overridden so "dist" depends on the targets > that build jars: depends="jar,sources,common-build.dist" /> In common-build-webapp > "dist" is overridden so it depends on the target that build a war. In > common-build-flex "dist" is overridden so it depends on the target > that build a swf. > And here comes the trouble: multi "inheritance" doesn't work well. Yes. I think this is the exact reason for target-groups. 's target overriding doesn't work well and it is a lot easier to inject your own targets into depends lists than to override existing targets and ensure you get the original depends lists right. > But using target groups expect me to know which part of the > common-build can be extended. It takes planning 8-) > To conclude, I don't know if opening up targets dependency can be that > useful, I think your post makes a point that there are targets that are designed to be extended and others that are not. If we removed the target-group and made all depends lists modifiable, we'd lose a way to signal which targets are to be extended and which not (not that we had such a mechanism before target-group was introduced). > Now thinking loud, maybe a simple attribute on target like > dependencies="public" would also fit ? Likely coupled with changing the current target-group name. Only thinking loudly as well we could turn into and would do away with any notion of target composition people way expect from the name target-*group*. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Maybe we should open up "depends" for all targets [again]
Well, the title of this mail is referencing [1], as announced I was thinking that we should, but after gathering my ideas and writing this email, I am not so sure. So was introduced lately the concept of target group in Ant. I found it quite interesting as it would help writing sharable ant script, just as it is used in EasyAnt. I have a "build system" to maintain, shared between several different kind of project, simple java ones, webapp ones, flex app ones, flex lib ones, webservice ones, etc... All of these projects share the same release process and dependency management (Ivy of course ;) ). So I have a common-build.xml, a common-build-java.xml, a common-build-webapp.xml, a common-build-flex, etc... There is some sort of inheritance between those build scripts: common-build-java.xml depends on common-build.xml, common-build-webapp.xml depends on common-build.java, etc... I have a "dist" target in common-build which expect things to be build before being published with Ivy. Then in common-build-java I have targets to build jars, and "dist" is overridden so "dist" depends on the targets that build jars: In common-build-webapp "dist" is overridden so it depends on the target that build a war. In common-build-flex "dist" is overridden so it depends on the target that build a swf. And here comes the trouble: multi "inheritance" doesn't work well. If I have a webapp project that require some flex to be build, here comes the mess. Depending of the order of import of common-build-webapp.xml and common-build-flex.xml, either the flex will be published, either the war. I have to override "dist" in the project's build.xml so it explicitly call the build of the java, the swc and the war. Here would help target group. If I define "dist" a target group, everything will then work fine. And I think that attaching a target to a target group is a way more proper than overriding targets, as it doesn't change any dependency declared between targets in common-build, it just adds new ones. If I focus on seeing an Ant build script as a DAG (direct acyclic graph), properly overriding a DAG seems to me just adding new edges and targets, not changing them. And many overriding (which we can see as multi inheritance) can apply without interacting. Adding targets to the dependency of another target (as target groups do) seems to be the way to go. But using target groups expect me to know which part of the common-build can be extended. And I got every day some new need on some project that require a specific move in the common-build workflow. On the other hand, if I today look closely to the 2200 lines of the common build files I maintain, I have very few targets that I need to be changed as a target group. And for most of them, they are already empty of tasks. The actual heavy customization required by some project, are done in the project itself. In the project itself I don't need to care about reusability or extension, so target overriding is fine. To conclude, I don't know if opening up targets dependency can be that useful, I don't know if there is real use case where you want a spaghetti of target dependencies to be opened to a third party. Maybe it is better to explicit where target dependencies can be injected by using a special element, the target groups. Now thinking loud, maybe a simple attribute on target like dependencies="public" would also fit ? Nicolas [1] http://old.nabble.com/Maybe-we-should-open-up-%22depends%22-for-all-targets-p20603861.html - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
