You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2008/11/11 12:25:44 UTC
EasyAnt phases
Hi all,
EasyAnt has a concept named "phase" which is some special sort of
target. The main differences:
* is always empty
* its depends list is open for other targets to modify, i.e. targets
may add themselves as dependencies to a phase.
It has been suggested to rename "phase" to "target-group".
Without going into implementation details, do we want to add the
concept itself to Ant's core?
If we don't I'll volunteer to help the EasyAnt people to hook the
concept into Ant without patching Ant itself.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Dominique Devienne <dd...@gmail.com>.
On Tue, Nov 11, 2008 at 5:25 AM, Stefan Bodewig <bo...@apache.org> wrote:
> Without going into implementation details, do we want to add the
> concept itself to Ant's core?
+1 on the concept. Back in the days trying to design reusable builds
around Ant's import, this would have made my life tons easier.
To comment on Jeffrey's -0, I don't think this is something that can
be implemented independently of Ant, and it's something that cleanly
replaces the proposed pre and post targets, which were generally
discussed as necessary. I'm happy to document it as experimental and
possibly removed in the future if it doesn't pan out though.
-0 to the phase name.
+1 to the target-group name.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Jean-Louis BOUDART <je...@gmail.com>.
>
> > By typing "ant test -Dskip.test=true" you will not execute any target
> > related to test target-group.
>
> Hmmm, I thought a target group basically had it's depends attribute
> basically rewritten to include whatever target declared itself to be
> part of this group, and since if/unless apply to the target's body and
> not its dependencies, if/unless would have been useless on
> target-groups.
>
> So either I assumed incorrectly how target-group was implemented, or
> what you describe above (assuming depends attribute re-writing) is
> incorrect. So which is it?
*hides*
My bad, i merged two different things in my answer :)
Currently if /unless attribute is ignored on target-group.
But it could be interresting feature (not yet implemented) to support that
attribute to "skip" all task related to a given phase
Re: EasyAnt phases
Posted by Dominique Devienne <dd...@gmail.com>.
On Tue, Nov 18, 2008 at 10:07 AM, Jean-Louis BOUDART
<je...@gmail.com> wrote:
> As target-group is nothing more than a "target" so if/unless attribute is
> supported.
> Exemple
> <project>
> <target-group name="test" depends="other-targetgroup" description="..."
> unless="skip.test"/>
> <target name="myTestTarget" depends="whatever" phase="test">
> ...
> </target>
> </project>
> By typing "ant test" you will execute ALL target related to test
> target-group
So far so good.
> By typing "ant test -Dskip.test=true" you will not execute any target
> related to test target-group.
Hmmm, I thought a target group basically had it's depends attribute
basically rewritten to include whatever target declared itself to be
part of this group, and since if/unless apply to the target's body and
not its dependencies, if/unless would have been useless on
target-groups.
So either I assumed incorrectly how target-group was implemented, or
what you describe above (assuming depends attribute re-writing) is
incorrect. So which is it?
> In opposite,
> if you wanna execute explicitly "ant myTestTarget", phase attribute is
> ignored (so skip.attribute should not be applied).
That makes perfect sense. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Sorry i'm missed this mail
2008/11/14 Gilles Scokart <gs...@gmail.com>
> 2008/11/13 Gilles Scokart <gs...@gmail.com>:
> > I'm +1 to put the concept in Ant's core, marked as experimental.
> >
> > A question that I have is how deep we want to push this concept?
> >
> > A first level would be that a phase or a target-group is a "normal"
> > tartget for which the depends is build based on the other target that
> > are found. (with that view, I wonder by the way what motivate the fact
> > that the phase have no tasks).
>
IMHO target-group are more powerfull when depending on other target-groups.
I think this kind of target should stay as abstract as possible.
This allow you more flexibilty.
> >
> > A second level (maybe I go too far) might be to put it deeper up to
> > the event notification. A build that use phase might have
> > phaseStarted and phaseFinished event sent around targetStarted and
> > targetFinished.
>
This could be interresting
A third level (or 2bis) : what will be the meaning if the if/unless
> attribute on a phase ?
> With the simple aproach in which phase are 'simple' targets, it does
> nothing. But I think it would be more intuitice if that would mean
> "do or skip all the target bound in that phase.
As target-group is nothing more than a "target" so if/unless attribute is
supported.
Exemple
<project>
<target-group name="test" depends="other-targetgroup" description="..."
unless="skip.test"/>
<target name="myTestTarget" depends="whatever" phase="test">
...
</target>
</project>
By typing "ant test" you will execute ALL target related to test
target-group
By typing "ant test -Dskip.test=true" you will not execute any target
related to test target-group.
In opposite,
if you wanna execute explicitly "ant myTestTarget", phase attribute is
ignored (so skip.attribute should not be applied).
Jean Louis
Re: EasyAnt phases
Posted by Gilles Scokart <gs...@gmail.com>.
2008/11/13 Gilles Scokart <gs...@gmail.com>:
> I'm +1 to put the concept in Ant's core, marked as experimental.
>
> A question that I have is how deep we want to push this concept?
>
> A first level would be that a phase or a target-group is a "normal"
> tartget for which the depends is build based on the other target that
> are found. (with that view, I wonder by the way what motivate the fact
> that the phase have no tasks).
>
> A second level (maybe I go too far) might be to put it deeper up to
> the event notification. A build that use phase might have
> phaseStarted and phaseFinished event sent around targetStarted and
> targetFinished.
>
A third level (or 2bis) : what will be the meaning if the if/unless
attribute on a phase ?
With the simple aproach in which phase are 'simple' targets, it does
nothing. But I think it would be more intuitice if that would mean
"do or skip all the target bound in that phase.
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: EasyAnt phases
Posted by Ja...@rzf.fin-nrw.de.
> > There is one change: the current Ant behavior is to respect the
order in
> > which dependencies are set. The phase as currently proposed does not
deal
> > with this, making it only usable in certain use cases.
>
> Someone correct me if I'm wrong here, but AFAIK there's nothing in the
> documentation that states target dependencies will be executed in the
> order listed. The fact that the default executor respects the order is
a
> side effect of the implementation, not a guaranteed behavior.
While implementing the ParallelExecutor in the sandbox I got reaction in
that case.
http://marc.info/?l=ant-user&m=119797310406425&w=2
Basically order does matter (at the moment).
But this was the basic idea of that executor: start all targets from the
depends clause
in parallel and start executing the current target if all finished
without failure.
But someone pointed out
(http://marc.info/?l=ant-user&m=119797614510909&w=2) that the manual
itself gives that hint: http://ant.apache.org/manual/using.html#targets
"It should be noted, however, that Ant's depends attribute only
specifies the order in
which targets should be executed - it does not affect whether the
target that specifies
the dependency(s) gets executed if the dependent target(s) did not
(need to) run.
Ant tries to execute the targets in the depends attribute in the order
they appear (from
left to right). Keep in mind that it is possible that a target can get
executed earlier
when an earlier target depends on it."
The need of clarification was said in
http://marc.info/?l=ant-user&m=119797869814067&w=2
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Here is some additional information on EasyAnt phase concept
http://easyant.abrm.info/trac/wiki/tasks/phase
Re: EasyAnt phases
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Nov 13, 2008 at 1:44 PM, Gilles Scokart <gs...@gmail.com> wrote:
> A second level (maybe I go too far) might be to put it deeper up to
> the event notification. A build that use phase might have
> phaseStarted and phaseFinished event sent around targetStarted and
> targetFinished.
Makes sense to me. The Default Logger (or maybe another
logger/listener) would then display target group information, helping
make sense of the build output. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Gilles Scokart <gs...@gmail.com>.
I'm +1 to put the concept in Ant's core, marked as experimental.
A question that I have is how deep we want to push this concept?
A first level would be that a phase or a target-group is a "normal"
tartget for which the depends is build based on the other target that
are found. (with that view, I wonder by the way what motivate the fact
that the phase have no tasks).
A second level (maybe I go too far) might be to put it deeper up to
the event notification. A build that use phase might have
phaseStarted and phaseFinished event sent around targetStarted and
targetFinished.
2008/11/11 Stefan Bodewig <bo...@apache.org>:
> Hi all,
>
> EasyAnt has a concept named "phase" which is some special sort of
> target. The main differences:
>
> * is always empty
>
> * its depends list is open for other targets to modify, i.e. targets
> may add themselves as dependencies to a phase.
>
> It has been suggested to rename "phase" to "target-group".
>
> Without going into implementation details, do we want to add the
> concept itself to Ant's core?
>
> If we don't I'll volunteer to help the EasyAnt people to hook the
> concept into Ant without patching Ant itself.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Remie Bolte <re...@backbase.com>.
I agree that it doesn't make it right, however, it makes it a point to
consider.
One might even argue that the two do not exclude each other: in the current
implementation an order depending design pattern and a DAG implementation
can co-exist. Personally I would not vote for enforcing either design
pattern for I think both have merit.
Hence I also believe that it would serve the community to enable the
possibility of ordered execution in the target-group / phase element. Maybe
not as default behavior, but as additional feature. It doesn't make it
right, but it probably will makes someones life a bit easier :)
-r
On Wed, Nov 12, 2008 at 6:37 PM, Jeffrey E Care <ca...@us.ibm.com> wrote:
> "Remie Bolte" <re...@backbase.com> wrote on 11/12/2008 11:42:05 AM:
>
> > > By declaring your target to be part of a given group, you are indeed
> > > adding yourself as an *unordered* dependency on that phase (which is
> > > just like a body-less target), but as you target you still have
> > > dependencies, on other targets *or* target groups which will be what
> > > dictates the ordering. If you specify your dependencies correctly, the
> > > order will be correct. That's always been the case, and target groups
> > > don't change that.
> >
> > There is one change: the current Ant behavior is to respect the order in
> > which dependencies are set. The phase as currently proposed does not
> deal
> > with this, making it only usable in certain use cases.
>
> Someone correct me if I'm wrong here, but AFAIK there's nothing in the
> documentation that states target dependencies will be executed in the
> order listed. The fact that the default executor respects the order is a
> side effect of the implementation, not a guaranteed behavior.
>
> The fact that many projects do in fact rely on target dependencies being
> executed in listed order doesn't make it right.
Re: EasyAnt phases
Posted by Jeffrey E Care <ca...@us.ibm.com>.
"Remie Bolte" <re...@backbase.com> wrote on 11/12/2008 11:42:05 AM:
> > By declaring your target to be part of a given group, you are indeed
> > adding yourself as an *unordered* dependency on that phase (which is
> > just like a body-less target), but as you target you still have
> > dependencies, on other targets *or* target groups which will be what
> > dictates the ordering. If you specify your dependencies correctly, the
> > order will be correct. That's always been the case, and target groups
> > don't change that.
>
> There is one change: the current Ant behavior is to respect the order in
> which dependencies are set. The phase as currently proposed does not
deal
> with this, making it only usable in certain use cases.
Someone correct me if I'm wrong here, but AFAIK there's nothing in the
documentation that states target dependencies will be executed in the
order listed. The fact that the default executor respects the order is a
side effect of the implementation, not a guaranteed behavior.
The fact that many projects do in fact rely on target dependencies being
executed in listed order doesn't make it right.
Re: EasyAnt phases
Posted by Remie Bolte <re...@backbase.com>.
> By declaring your target to be part of a given group, you are indeed
> adding yourself as an *unordered* dependency on that phase (which is
> just like a body-less target), but as you target you still have
> dependencies, on other targets *or* target groups which will be what
> dictates the ordering. If you specify your dependencies correctly, the
> order will be correct. That's always been the case, and target groups
> don't change that.
There is one change: the current Ant behavior is to respect the order in
which dependencies are set. The phase as currently proposed does not deal
with this, making it only usable in certain use cases.
As a separate note, it's bad practice IMHO to rely on dependencies to
> execute in the order a target specifies them. You should think in
> terms of requirements for the target to complete successfully, and not
> worry about the order. There's even a custom target executor that
> removes the default Ant behavior to honor the order of the direct
> dependencies and simply relies on the DAG topological sort, which is
> the way to go in fact. --DD
Dependencies in any way always have a specific order: you have a list of
requirements, and sometimes they themselves also have a list of
requirements, creating a nested dependency relationship. In complex designs,
this will automatically result in a DAG scheme for the nested dependencies
will probably have overlap. We are currently implementing the same view in
our product builds. For optimization reasons, we use conditions to prevent
duplicate execution of targets.
Having said that, there are use-cases in which having an ordered execution
of depending products makes sense, where implementing a DAG scheme would
make our world more complex than truly required. It is probably also this
pragmatic approach that caused the default target executor in Ant to still
respect the dependency order. That same pragmatic argument could be used in
this discussion: it would be a nice-to-have if it would be possible to
influence the order in which targets are executed in the phase.
However, I do see that this feature request creates an implementation
nightmare :)
Cheers,
Remie
Re: EasyAnt phases
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Nov 12, 2008 at 6:00 AM, Remie Bolte <re...@backbase.com> wrote:
> Thanks for the explanation, it indeed seems to be a nice feature, however my
> first concern would be the order of execution.
It's no different from the current behavior Remie.
target-groups or phases are indeed just like target dependency
injection (good analogy Jeffrey!).
By declaring your target to be part of a given group, you are indeed
adding yourself as an *unordered* dependency on that phase (which is
just like a body-less target), but as you target you still have
dependencies, on other targets *or* target groups which will be what
dictates the ordering. If you specify your dependencies correctly, the
order will be correct. That's always been the case, and target groups
don't change that.
As a separate note, it's bad practice IMHO to rely on dependencies to
execute in the order a target specifies them. You should think in
terms of requirements for the target to complete successfully, and not
worry about the order. There's even a custom target executor that
removes the default Ant behavior to honor the order of the direct
dependencies and simply relies on the DAG topological sort, which is
the way to go in fact. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-14, Remie Bolte <re...@backbase.com> wrote:
> Perhaps it is possible to create a dependency between phases, and
> additionally give targets the possibility to depend on a phase i.e.:
> <phase name="phase1" targets="targetA, targetB, targetC" />
> <phase name="phase2" targets="targetD, targetE" depends="phase1" />
> <phase name="phase3" depends="phase1, phase2" />
> <target name="compile" register-to="phase3" />
> <target name="build" depends="phase3" />
As EasyAnt's implementation stands, phases *are* targets, this means
(or should mean) that targets and phases can depend on targets and
phases.
> Thanks again for taking the time to explain certain behavior and past
> considerations. Some of my comments and suggestions might feel redundant for
> those might have already been discussed in the past.
Don't worry. Sometimes the one explaining something learns more by
the very process of doing it than the one who listens, in in this case
it may help us get the concept "right".
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Remie Bolte <re...@backbase.com>.
Perhaps it is possible to create a dependency between phases, and
additionally give targets the possibility to depend on a phase i.e.:
<phase name="phase1" targets="targetA, targetB, targetC" />
<phase name="phase2" targets="targetD, targetE" depends="phase1" />
<phase name="phase3" depends="phase1, phase2" />
<target name="compile" register-to="phase3" />
<target name="build" depends="phase3" />
(please don't mind the names, i'm not following this topic close enough to
know them or make suggestions, it's just an example).
This way it is possible for a target to rely on having a certain build
phases executed. Personally, I don't see a good way of implementing ordering
in phases, wheter or not this is desired. However, I think the concept of
ordering and the community dependency on this behavior should be taken into
this discussion. That was the only point I tried to make :)
BTW: there are situation in our product builds where we specify the
dependencies the way described by Dominique, using the antContrib runtarget
task. I can image that having a dependency task that can be placed at any
point inside a target allows more flexibility.
Cheers,
Remie
p.s.
Thanks again for taking the time to explain certain behavior and past
considerations. Some of my comments and suggestions might feel redundant for
those might have already been discussed in the past.
On Fri, Nov 14, 2008 at 6:02 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2008-11-13, Bruce Atherton <br...@callenish.com> wrote:
>
> > Conceptually I agree with you, but I think we need to recognize why
> > people would want this and to validate their concerns.
>
> I wasn't advocating we change the current behavior, Ant's own build
> file relies on it in much the same way as
>
> > Consider these targets:
>
> > <target name="full-build" depends="clean,compile,jar-files">...</target>
> > <target name="update-build" depends="compile,jar-files">...</target>
>
> for example see the way we structure our test targets.
>
> <target name="run-tests"
> depends="dump-info,junit-tests,antunit-tests,check-failed"
>
> and "check-failed" doesn't depend on anything, so with a different
> executor model it might be run before any test has started.
>
> In the context of phases I think we don't need control over ordering
> since the targets that want to add themselves to phases shouldn't
> really depend on each other. If they do - that's what I meant to say
> - then it smells as if an additional intermediate phase was missing.
>
> But your example got me thinking. It is pretty easy to imagine that
> there would be "build" and "clean-build" phases much like what you
> have shown with target. If my target wants to do something only in
> the clean-build phase it will most likely make a difference whether it
> is run before or after "clean".
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-13, Bruce Atherton <br...@callenish.com> wrote:
> Conceptually I agree with you, but I think we need to recognize why
> people would want this and to validate their concerns.
I wasn't advocating we change the current behavior, Ant's own build
file relies on it in much the same way as
> Consider these targets:
> <target name="full-build" depends="clean,compile,jar-files">...</target>
> <target name="update-build" depends="compile,jar-files">...</target>
for example see the way we structure our test targets.
<target name="run-tests"
depends="dump-info,junit-tests,antunit-tests,check-failed"
and "check-failed" doesn't depend on anything, so with a different
executor model it might be run before any test has started.
In the context of phases I think we don't need control over ordering
since the targets that want to add themselves to phases shouldn't
really depend on each other. If they do - that's what I meant to say
- then it smells as if an additional intermediate phase was missing.
But your example got me thinking. It is pretty easy to imagine that
there would be "build" and "clean-build" phases much like what you
have shown with target. If my target wants to do something only in
the clean-build phase it will most likely make a difference whether it
is run before or after "clean".
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Maybe we should open up "depends" for all targets
Posted by Gilles Scokart <gs...@gmail.com>.
2008/11/21 Stefan Bodewig <bo...@apache.org>:
> On 2008-11-20, Dominique Devienne <dd...@gmail.com> wrote:
>
>> On Thu, Nov 20, 2008 at 10:21 AM, Stefan Bodewig <bo...@apache.org> wrote:
>>> target-group is-a target. A "plain target" is a target as opposed to
>>> a target-group.
>
>> Since I have conceptualized them in my head as something different
>> than targets, I forget that implementation-wise they remain targets.
>
> Not only implementation-wise, also in my head, conceptually.
>
>> I actually think it would be better if the code made them distinct
>> classes, possibly extracting an interface for the perform and
>> dependency getting parts, but that's a different story. From the
>> user and documentation perspective, the fact that a target-group is
>> a target under the cover should be de-emphasized IMHO.
>
> I wonder what sort of difference between target and target-group
> people see, I don't seem to get it, sorry.
>
> Stefan
>
I'm not sure exactely of what sort of difference I see (normal because
we didn't manage to define it), but here my "feeling" about the
difference :
- There is a difference of granularity.
- Between targets, you have a relations of prerequisites. A target
depends on things being produced by other target (that the dependee
target knows).
- Between targets and target-group, you have an idea of 'PartOf'
relationship (with only the part having knowledge of its group).
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Maybe we should open up "depends" for all targets
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-20, Dominique Devienne <dd...@gmail.com> wrote:
> On Thu, Nov 20, 2008 at 10:21 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> target-group is-a target. A "plain target" is a target as opposed to
>> a target-group.
> Since I have conceptualized them in my head as something different
> than targets, I forget that implementation-wise they remain targets.
Not only implementation-wise, also in my head, conceptually.
> I actually think it would be better if the code made them distinct
> classes, possibly extracting an interface for the perform and
> dependency getting parts, but that's a different story. From the
> user and documentation perspective, the fact that a target-group is
> a target under the cover should be de-emphasized IMHO.
I wonder what sort of difference between target and target-group
people see, I don't seem to get it, sorry.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Maybe we should open up "depends" for all targets
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Nov 20, 2008 at 10:21 AM, Stefan Bodewig <bo...@apache.org> wrote:
> target-group is-a target. A "plain target" is a target as opposed to
> a target-group.
Since I have conceptualized them in my head as something different
than targets, I forget that implementation-wise they remain targets. I
actually think it would be better if the code made them distinct
classes, possibly extracting an interface for the perform and
dependency getting parts, but that's a different story. From the user
and documentation perspective, the fact that a target-group is a
target under the cover should be de-emphasized IMHO. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Gilles Scokart <gs...@gmail.com>.
2008/11/21 Stefan Bodewig <bo...@apache.org>:
> On 2008-11-20, Gilles Scokart <gs...@gmail.com> wrote:
>
>> 2008/11/20 Stefan Bodewig <bo...@apache.org>:
>>> On 2008-11-20, Gilles Scokart <gs...@gmail.com> wrote:
>
>>>> - What about the if/unless?
>
>>> This would be pretty hard to implement as you saw yourself later on.
>>> What if the same target is in the depends list of two different
>>> target-groups?
>
>> What about making an 'or' between the conditions ?
>
> Is this really what would be intended? What if one target-group has
> an if attribute while the other one has not, or if the have
> contradicting attributes?
>
> Stefan
The idea is to plug a target into a target group. If a target is
plugged into 2 target-group, and only one target group needs to be
executed, then that target still needs to be executed to satisfy the
execution of the other group.
Concerning the conflict, we already have it with if and unless (it is
just that they are closer).
But I agree, it might be confusing. At least until we found a right
view for the target and the target-group (something that I feel we
don't have yet).
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-20, Gilles Scokart <gs...@gmail.com> wrote:
> 2008/11/20 Stefan Bodewig <bo...@apache.org>:
>> On 2008-11-20, Gilles Scokart <gs...@gmail.com> wrote:
>>> - What about the if/unless?
>> This would be pretty hard to implement as you saw yourself later on.
>> What if the same target is in the depends list of two different
>> target-groups?
> What about making an 'or' between the conditions ?
Is this really what would be intended? What if one target-group has
an if attribute while the other one has not, or if the have
contradicting attributes?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Gilles Scokart <gs...@gmail.com>.
2008/11/20 Stefan Bodewig <bo...@apache.org>:
> On 2008-11-20, Gilles Scokart <gs...@gmail.com> wrote:
>
>> There is 2 other topics :
>> - What about the build events?
>
> As long as target-groups are not different from targets from the
> perspective of the person who runs ant, not the person who writes the
> build file, I don't see why.
We are in line.
>
>> - What about the if/unless?
>
> This would be pretty hard to implement as you saw yourself later on.
> What if the same target is in the depends list of two different
> target-groups?
What about making an 'or' between the conditions ? Am I still biased
by a view "targets are put inside a target-group" ?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-20, Gilles Scokart <gs...@gmail.com> wrote:
> There is 2 other topics :
> - What about the build events?
As long as target-groups are not different from targets from the
perspective of the person who runs ant, not the person who writes the
build file, I don't see why.
> - What about the if/unless?
This would be pretty hard to implement as you saw yourself later on.
What if the same target is in the depends list of two different
target-groups?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Gilles Scokart <gs...@gmail.com>.
2008/11/19 Bruce Atherton <br...@callenish.com>:
> I think that summary does the job nicely. The only other topic I saw brought
> up on this thread was whether a target-group should be allowed to have tasks
> in it rather than requiring it to be empty. This can also be discussed
> separately, though, if people feel strongly enough about it.
>
There is 2 other topics :
- What about the build events?
- What about the if/unless?
Concerning the build events, It looks a very nice feature, but digging
deeper I fear it doesn't work :
<project>
<target-group name="foo"/>
<target-group name="bar" depends="bar"/>
<target name="init" target-group ="foo,bar"/>
</project>
In which group do you have init executed? The current interpretation
is "targets are not executed inside a group, they are executed before
the group is executed".
A more interresting example is :
<project>
<target-group name="foo"/>
<target-group name="bar" depends="bar"/>
<target name="a" target-group ="bar"/>
<target name="b" depends="a" target-group ="foo"/>
</project>
The execution sequence will be a , b , foo , bar.
This illustrates the view target-group is a group of targets inside
which the targets are executed is wrong, and thus my idea of having
events was wrong.
Perhaps we should rename the concepts to not give the impression that
this is something 'inside' which you can plug target. What about
'milestone', 'step', 'dynamic-target', 'goal' (who said 'phase'?).
Concerning the if/unless, however, I still like the idea. Maybe the
targets having a target-group should copy the if/unless of their
target-group? (problem comes when there are multiple if/unless...)
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Maybe we should open up "depends" for all targets
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-20, Dominique Devienne <dd...@gmail.com> wrote:
> On Thu, Nov 20, 2008 at 9:32 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> The *only* differences between <target> and <target-group> in trunk
>> are:
>> * <target-group>s must be empty
> I like that.
>> * you cannot use the target-group attribute to change the depends list
>> of a plain target
> Hmmm, you've lost me again ;) What's a plain target? If it's one w/o a
> (target-)?group attribute, the above sentence has a logical
> contradiction that throws me off.
target-group is-a target. A "plain target" is a target as opposed to
a target-group.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Maybe we should open up "depends" for all targets
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Nov 20, 2008 at 9:32 AM, Stefan Bodewig <bo...@apache.org> wrote:
> <target name="a"/>
> <target name="b" target-group="a"/>
[OT] I recently was thinking that <target ... target-group="..." /> is "heavy".
I think using <target ... group="..." /> is just as expressive.
> The *only* differences between <target> and <target-group> in trunk
> are:
> * <target-group>s must be empty
I like that.
> * you cannot use the target-group attribute to change the depends list
> of a plain target
Hmmm, you've lost me again ;) What's a plain target? If it's one w/o a
(target-)?group attribute, the above sentence has a logical
contradiction that throws me off.
> <target name="b" before="a"> [...]
> and we don't need <target-group> at all. [...]
> This is just an idea, not that I'm conviced of it myself.
Now that I've been introduced to the notion of target group, I prefer
it to the before/after we were discussing earlier.
Target groups allow to define to high level structure of a build, it's
"flow" in a way, and builds to cleanly hook up into this flow.
It's a cleaner abstraction than the before/after one, and which I feel
would encourage before build designs. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Maybe we should open up "depends" for all targets
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-20, Dominique Devienne <dd...@gmail.com> wrote:
> On Wed, Nov 19, 2008 at 11:19 PM, Stefan Bodewig <bo...@apache.org> wrote:
>> On 2008-11-19, Bruce Atherton <br...@callenish.com> wrote:
>>> The only other topic I saw brought up on this thread was whether a
>>> target-group should be allowed to have tasks in it rather than
>>> requiring it to be empty.
>> If we allwed them to e non-empty, we could do away with target-group
>> completely and simply open up the depends list of all targets.
> Sorry, I'm not getting this. Can you expand on what you mean please? --DD
Technically you can change the depends list of any target during
parsing, it is ProjectHelper2 that will prevent you from doing
<target name="a"/>
<target name="b" target-group="a"/>
and it is going to tell you that "a" is not a target-group.
The *only* differences between <target> and <target-group> in trunk
are:
* <target-group>s must be empty
* you cannot use the target-group attribute to change the depends list
of a plain target
If we do away with the first one, why not with the second one as well?
<target name="a">
<task1/>
<task2/>
</target>
<target name="b" before="a">
<taskA/>
<taskB/>
</target>
and we don't need <target-group> at all.
The documentation would say "don't use before to modify the depends
list of a target defined in the same file, use the depends-attribute
for that", but it should say the same for target-groups currently as
well.
This is just an idea, not that I'm conviced of it myself.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Dominique Devienne <dd...@gmail.com>.
On Wed, Nov 19, 2008 at 11:19 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2008-11-19, Bruce Atherton <br...@callenish.com> wrote:
>
>> The only other topic I saw brought up on this thread was whether a
>> target-group should be allowed to have tasks in it rather than
>> requiring it to be empty.
>
> If we allwed them to e non-empty, we could do away with target-group
> completely and simply open up the depends list of all targets.
Sorry, I'm not getting this. Can you expand on what you mean please? --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-18, Matt Benson <gu...@yahoo.com> wrote:
> it would seem the API necessary for a custom ProjectHelper to do
> this already exists...
absolutely.
The question was whether ProjectHelper2 should do it directly.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On 2008-11-18, Jean-Louis BOUDART
> <je...@gmail.com> wrote:
>
> > So any conclusions?
>
> At least no consensus.
>
> I'm not sure whether Matt is -0 or -1 on the
> concept.
At worst I'd be -0. :) Really if a target group is
just a target whose dependencies can be joined at will
be other targets, it would seem the API necessary for
a custom ProjectHelper to do this already exists... so
it's not a huge deal either way...
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-18, Jean-Louis BOUDART <je...@gmail.com> wrote:
> So any conclusions?
At least no consensus.
I'm not sure whether Matt is -0 or -1 on the concept.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-19, Bruce Atherton <br...@callenish.com> wrote:
> The only other topic I saw brought up on this thread was whether a
> target-group should be allowed to have tasks in it rather than
> requiring it to be empty.
If we allwed them to e non-empty, we could do away with target-group
completely and simply open up the depends list of all targets.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Bruce Atherton <br...@callenish.com>.
I think that summary does the job nicely. The only other topic I saw
brought up on this thread was whether a target-group should be allowed
to have tasks in it rather than requiring it to be empty. This can also
be discussed separately, though, if people feel strongly enough about it.
Stefan Bodewig wrote:
>
> OK, with Matt's recent response it sounds as if we could add
> target-group as a new kind of target that is always empty and whose
> depends list other targets may append to while the build file is
> parsed.
>
> IMHO this much can be added to core right away.
>
> There have been discussions on whether we'd need more control over
> ordering of dependencies or a different interpretation of if/unless
> but these can be solved separately.
>
> Does that summary sound correct?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-18, Jean-Louis BOUDART <je...@gmail.com> wrote:
> So any conclusions?
> Does this feature should be integrated to ant-core?
OK, with Matt's recent response it sounds as if we could add
target-group as a new kind of target that is always empty and whose
depends list other targets may append to while the build file is
parsed.
IMHO this much can be added to core right away.
There have been discussions on whether we'd need more control over
ordering of dependencies or a different interpretation of if/unless
but these can be solved separately.
Does that summary sound correct?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Jean-Louis BOUDART <je...@gmail.com>.
So any conclusions?
Does this feature should be integrated to ant-core? or prove it's
usefulness in EasyAnt & move it into core later if it truly proves useful ?
2008/11/14 Dominique Devienne <dd...@gmail.com>
> On Fri, Nov 14, 2008 at 7:55 AM, Stefan Bodewig <bo...@apache.org>
> wrote:
> > On 2008-11-13, Dominique Devienne <dd...@gmail.com> wrote:
> >
> >> This would be cleanly solved by the proto shown once a long time ago
> >> by Conor (I believe), where dependencies could be specified *inside*
> >> the target body.
> >
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=12292
> >
> > opened by Nicola Ken six years ago, with patch.
>
> Man, you're good :) I remembered the idea came from one of the Ant2
> protos, but not that Nicola Ken actually implemented it.
>
> I guess if it didn't fly then, it won't fly now tough. I'm actually
> having trouble wrapping my head around all the ramifications this
> would open, when I try to sort it out a bit more ;) --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt phases
Posted by Dominique Devienne <dd...@gmail.com>.
On Fri, Nov 14, 2008 at 7:55 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2008-11-13, Dominique Devienne <dd...@gmail.com> wrote:
>
>> This would be cleanly solved by the proto shown once a long time ago
>> by Conor (I believe), where dependencies could be specified *inside*
>> the target body.
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=12292
>
> opened by Nicola Ken six years ago, with patch.
Man, you're good :) I remembered the idea came from one of the Ant2
protos, but not that Nicola Ken actually implemented it.
I guess if it didn't fly then, it won't fly now tough. I'm actually
having trouble wrapping my head around all the ramifications this
would open, when I try to sort it out a bit more ;) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-13, Dominique Devienne <dd...@gmail.com> wrote:
> This would be cleanly solved by the proto shown once a long time ago
> by Conor (I believe), where dependencies could be specified *inside*
> the target body.
https://issues.apache.org/bugzilla/show_bug.cgi?id=12292
opened by Nicola Ken six years ago, with patch.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Nov 13, 2008 at 1:08 PM, Bruce Atherton <br...@callenish.com> wrote:
> Conceptually I agree with you, but I think we need to recognize why people
> would want this and to validate their concerns.
>
> Consider these targets:
>
> <target name="full-build" depends="clean,compile,jar-files">...</target>
> <target name="update-build" depends="compile,jar-files">...</target>
>
> Whether or not "clean" is a dependency of "compile" depends on the context
> "compile" is executed in. Now, it is possible to work around this but I am
> fairly sure that using dependencies as described above is a common
> implementation pattern for our users. I know that I have used it in the
> past, and probably will again. Sacrilege, I know. :-)
Very good example Bruce, thanks. I also relied on the ordering in this
case, and in my haste to advocate against relying on the ordering I
forgot about it ;)
The work around involves creating additional targets, which is
inconvenient and leads to my dreaded "spaghetti Ant code".
This would be cleanly solved by the proto shown once a long time ago
by Conor (I believe), where dependencies could be specified *inside*
the target body. This was a little mind-bending at first, but then you
realize it's like creating implicit unnamed targets, and it solves the
ordering issue nicely. Your above example would then become:
<target name="full-build">
<!- pre-clean stuff>
<dependencies targets="clean"/>
<!- post-clean stuff>
<dependencies targets="compile, jar-files"/>
</target>
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Bruce Atherton <br...@callenish.com>.
Conceptually I agree with you, but I think we need to recognize why
people would want this and to validate their concerns.
Consider these targets:
<target name="full-build" depends="clean,compile,jar-files">...</target>
<target name="update-build" depends="compile,jar-files">...</target>
Whether or not "clean" is a dependency of "compile" depends on the
context "compile" is executed in. Now, it is possible to work around
this but I am fairly sure that using dependencies as described above is
a common implementation pattern for our users. I know that I have used
it in the past, and probably will again. Sacrilege, I know. :-)
For this specific feature, though, I don't believe the target-group
should have ordering added to it. Specifying an order would needlessly
complicate the use of the feature, as well as promoting behaviour that
we generally consider "bad" for build systems. Since there is a
workaround (providing ordering through the dependency tree), I think the
unordered solution is better.
But I wanted to make sure we fully understand the cost to our users of
leaving it unordered.
Stefan Bodewig wrote:
>
> If you need a specific order of execution, you should ensure that your
> depends attributes are correct. If target "a" must be run before
> target "b" than "b" simply must depend upon "a".
>
> This is true with normal targets and I don't see why target-groups
> would change that.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Gilles Scokart <gs...@gmail.com>.
2008/11/13 Stefan Bodewig <bo...@apache.org>:
> On 2008-11-12, Remie Bolte <re...@backbase.com> wrote:
>
>> Thanks for the explanation, it indeed seems to be a nice feature, however my
>> first concern would be the order of execution.
>
> If you need a specific order of execution, you should ensure that your
> depends attributes are correct. If target "a" must be run before
> target "b" than "b" simply must depend upon "a".
>
> This is true with normal targets and I don't see why target-groups
> would change that.
>
My understanding is that the phase allow to incorporate targets that
doesn't know each other. In that context imposing an order doesn't
make sense.
But I can imagine that when implementing 2 independent sets of targets
to be bound in a phase, you realize that they will only work properly
together when executed in a specific order. For such a case, the user
will have no other choice than adding a phase. Indeed, he probably
doesn't know if the 2 sets of targets will be always used together.
If such scenario is realistics then, we may also need to have a
"depends if executed" meaning that if target b must be executed, then
it must be before target a.
I think some experimentation will say if such ordering mechanism is required.
At the opposite, I could also imagine that the implementation make
sure that the targets are isolated. I could imagine that the bounded
target are executed in isolation, and that all the properties and
reference that are defined are only visible when the phase is
finished.
I think both aproach are too extreme for the moment. The guideline
(and the purpose) should be to have the possibility to bind
independant targets into a phase.
>> If I understand correctly the target-group, or phase (would be my
>> preference), is a very top-level element that simply specifies a grouping of
>> tasks, it doesn't deal with the order in which tasks are performed.
>
> It really only is a target, yes. And it only exists for its depends
> list. If the targets it depends on require a specific order, they
> better say so in their own depends lists. If they can't, then this
> may hint at a missing phase.
>
>> So, this target-group element is only useful if order doesn't matter
>> in the phase, like in the example of having different types of
>> tests. If order does matter, this would then needed to be solved
>> using the depends attribute.
>
> Yes.
>
>> But that also requires making sure that certain targets are not
>> executed twice, which means one would need to add succeeded
>> properties and have unless conditions to check them, right?
>
> I don't think so. targets will never run twice unless you do
> something like running "ant a b" on the command line where b depends
> on a.
>
>> In addition, perhaps dynamic inclusion of build files (within targets) can
>> be a valuable extension to this phase feature.
>
> Right now <import> and <include> must be used outside of targets and
> it would be pretty difficult to implement in any other way.
>
> The imported files define new targets. If you import a file while
> executing a target you are modifiying the DAG of the running build
> targets.
>
>> Different question, but maybe related: is there a way to specify
>> that a build file should only be imported once (for instance, if
>> different nested files have import statements referring to the same
>> file)?
>
> This is the current behavior of <import>, any file will only be
> imported once and subsequent imports are ignored.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Gilles Scokart
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-12, Remie Bolte <re...@backbase.com> wrote:
> Thanks for the explanation, it indeed seems to be a nice feature, however my
> first concern would be the order of execution.
If you need a specific order of execution, you should ensure that your
depends attributes are correct. If target "a" must be run before
target "b" than "b" simply must depend upon "a".
This is true with normal targets and I don't see why target-groups
would change that.
> If I understand correctly the target-group, or phase (would be my
> preference), is a very top-level element that simply specifies a grouping of
> tasks, it doesn't deal with the order in which tasks are performed.
It really only is a target, yes. And it only exists for its depends
list. If the targets it depends on require a specific order, they
better say so in their own depends lists. If they can't, then this
may hint at a missing phase.
> So, this target-group element is only useful if order doesn't matter
> in the phase, like in the example of having different types of
> tests. If order does matter, this would then needed to be solved
> using the depends attribute.
Yes.
> But that also requires making sure that certain targets are not
> executed twice, which means one would need to add succeeded
> properties and have unless conditions to check them, right?
I don't think so. targets will never run twice unless you do
something like running "ant a b" on the command line where b depends
on a.
> In addition, perhaps dynamic inclusion of build files (within targets) can
> be a valuable extension to this phase feature.
Right now <import> and <include> must be used outside of targets and
it would be pretty difficult to implement in any other way.
The imported files define new targets. If you import a file while
executing a target you are modifiying the DAG of the running build
targets.
> Different question, but maybe related: is there a way to specify
> that a build file should only be imported once (for instance, if
> different nested files have import statements referring to the same
> file)?
This is the current behavior of <import>, any file will only be
imported once and subsequent imports are ignored.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Remie Bolte <re...@backbase.com>.
Hi,
Thanks for the explanation, it indeed seems to be a nice feature, however my
first concern would be the order of execution. I can imaging that the
easiest way to implement is a first-in-first-out approach (or
first-in-first-executed in this matter).
If I understand correctly the target-group, or phase (would be my
preference), is a very top-level element that simply specifies a grouping of
tasks, it doesn't deal with the order in which tasks are performed. The
required order is still defined using the depends attribute on targets. The
order of registered targets will be defined by the attribute on the
target-group, plus the targets that register themselves once they are loaded
(load order is defined by normal processing of targets and imported build
files).
So, this target-group element is only useful if order doesn't matter in the
phase, like in the example of having different types of tests. If order does
matter, this would then needed to be solved using the depends attribute. But
that also requires making sure that certain targets are not executed twice,
which means one would need to add succeeded properties and have unless
conditions to check them, right? Or spent time thinking about the order in
which targets or build files are imported into the project and processed.
Is there a way to solve the issue of ordered execution? I think that would
make it even more powerful.
In addition, perhaps dynamic inclusion of build files (within targets) can
be a valuable extension to this phase feature.
Different question, but maybe related: is there a way to specify that a
build file should only be imported once (for instance, if different nested
files have import statements referring to the same file)?
Cheers,
Remie
On Wed, Nov 12, 2008 at 8:21 AM, Jeffrey E Care <ca...@us.ibm.com> wrote:
>
> "Remie Bolte" <re...@backbase.com> wrote on 11/11/2008 11:05:48 AM:
>
> > Can you explain the concept of targets being able to add themselfs as
> > dependencies?
> > I can't really picture this :)
>
> I wasn't involved in the definition of this so don't take my word as
> gospel, but this is my understanding:
>
> Assume you have a lot of projects & want to define a standard set of build
> files (with a standard set of targets) for them all to use. You have a
> "test" target for each project that can run any number of other targets to
> perform specialized testing tasks: load testing, unit testing, etc.
>
> As things are today your standard test target needs to know about every
> potential kind of testing that ANY of the projects MIGHT need to do & add
> each of those other targets as a dependency. You basically then have to
> define an empty implementation of each one of those specialized targets in
> your standard set of build files, otherwise your test target will blow up
> when building against one of your projects that doesn't implement some
> particular kind of testing.
>
> This target-group concept turns that around; think of it as dependency
> injection. It's defining a target name and saying "Hey, if you want to be
> run when I run, please tell me" as opposed to the current situation of "Hey,
> I know what I need to do without any help". It's a callback, an extension
> point, an event listener, pick a metaphor.
> ____________________________________________________________________________________________
> Jeffrey E. (Jeff) Care *carej@us.ibm.com* <ca...@us.ibm.com>
> IBM WebSphere Application Server WAS Release Engineering
>
> [image: WebSphere Mosiac] [image: WebSphere Brandmark]
>
>
Re: EasyAnt phases
Posted by Jeffrey E Care <ca...@us.ibm.com>.
"Remie Bolte" <re...@backbase.com> wrote on 11/11/2008 11:05:48 AM:
> Can you explain the concept of targets being able to add themselfs as
> dependencies?
> I can't really picture this :)
I wasn't involved in the definition of this so don't take my word as
gospel, but this is my understanding:
Assume you have a lot of projects & want to define a standard set of build
files (with a standard set of targets) for them all to use. You have a
"test" target for each project that can run any number of other targets to
perform specialized testing tasks: load testing, unit testing, etc.
As things are today your standard test target needs to know about every
potential kind of testing that ANY of the projects MIGHT need to do & add
each of those other targets as a dependency. You basically then have to
define an empty implementation of each one of those specialized targets in
your standard set of build files, otherwise your test target will blow up
when building against one of your projects that doesn't implement some
particular kind of testing.
This target-group concept turns that around; think of it as dependency
injection. It's defining a target name and saying "Hey, if you want to be
run when I run, please tell me" as opposed to the current situation of
"Hey, I know what I need to do without any help". It's a callback, an
extension point, an event listener, pick a metaphor.
____________________________________________________________________________________________
Jeffrey E. (Jeff) Care
carej@us.ibm.com
IBM WebSphere Application Server
WAS Release Engineering
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-11, Remie Bolte <re...@backbase.com> wrote:
> Can you explain the concept of targets being able to add themselfs as
> dependencies?
> I can't really picture this :)
You have one build file with something like
<phase name="ready-to-compile" depends="setup"/>
<target name="compile" depends="ready-to-compile">
<javac .../>
</target>
as a template for Java compilation. This one gets imported or
included in another build file that needs to generate some source
files. This build file would contain
<target name="generate-sources" phase="ready-to-compile">
...
</target>
and the phase attribute would add "generate-sources" to the depends
attribute of "ready-to-compile".
This is useful for build files that explicitly want to define
extension points.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Remie Bolte <re...@backbase.com>.
Hi,
Can you explain the concept of targets being able to add themselfs as
dependencies?
I can't really picture this :)
Cheers,
Remie
On Tue, Nov 11, 2008 at 12:25 PM, Stefan Bodewig <bo...@apache.org> wrote:
> Hi all,
>
> EasyAnt has a concept named "phase" which is some special sort of
> target. The main differences:
>
> * is always empty
>
> * its depends list is open for other targets to modify, i.e. targets
> may add themselves as dependencies to a phase.
>
> It has been suggested to rename "phase" to "target-group".
>
> Without going into implementation details, do we want to add the
> concept itself to Ant's core?
>
> If we don't I'll volunteer to help the EasyAnt people to hook the
> concept into Ant without patching Ant itself.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt phases
Posted by Jeffrey E Care <ca...@us.ibm.com>.
-0 on the concept; my preference would be to let the function prove it's
usefulness in EasyAnt & move it into core later if it truly proves useful
-1 on the "phase" name
+1 on using "target-group" for the name
____________________________________________________________________________________________
Jeffrey E. (Jeff) Care
carej@us.ibm.com
IBM WebSphere Application Server
WAS Release Engineering
From:
Stefan Bodewig <bo...@apache.org>
To:
dev@ant.apache.org
Date:
11/11/2008 06:26 AM
Subject:
EasyAnt phases
Hi all,
EasyAnt has a concept named "phase" which is some special sort of
target. The main differences:
* is always empty
* its depends list is open for other targets to modify, i.e. targets
may add themselves as dependencies to a phase.
It has been suggested to rename "phase" to "target-group".
Without going into implementation details, do we want to add the
concept itself to Ant's core?
If we don't I'll volunteer to help the EasyAnt people to hook the
concept into Ant without patching Ant itself.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-13, Matt Benson <gu...@yahoo.com> wrote:
> --- Stefan Bodewig <bo...@apache.org> wrote:
>> On 2008-11-11, Matt Benson <gu...@yahoo.com>
>> wrote:
>>> Personally I would prefer supporting arbitrary attributes on
>>> targets.
>>> This would be less specific to EasyAnt and could have mileage for
>>> other Ant extensions.
Do you envision that we replace Target with UnknownElement and friends
or are you "just" thinking of a Property-Set that can be associated
with a target?
EasyAnt would still need a custom ProjectHelper to make sense of the
additional attributes, I don't see this as major a problem, though.
>> I read this as "I don't want the feature in core but provide hooks
>> to make live easier for EasyAnt", right?
> Pretty much, yeah, unless someone can make me see how "phases" (by
> whatever nomenclature) are relevant to basic Ant-fu. :)
OK, I'll try.
Take a look at the build file "infrastructure" (big word and it will
become worse ;-) for our antlibs, in particular
http://svn.apache.org/repos/asf/ant/antlibs/common/trunk/build.xml
It contains a number of empty targets with names like
"ready-to-compile" which are in there as extension points. If an
antlib needs to do something in addition to what ready-to-compile
does, it overrides the target with one of its own (which again depends
on the imported one).
This is a pattern you'll often find in build files designed for
re-use. I think Steve uses this in Smartfrog and I know I've used it
at work myself.
\begin{overstatement}
"phases" turn this design pattern into a language feature.
\end{overstatement}
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On 2008-11-11, Matt Benson <gu...@yahoo.com>
> wrote:
>
> > Personally I would prefer supporting arbitrary
> > attributes on targets.
>
> That would be easy to do.
>
> > This would be less specific to EasyAnt and could
> have mileage for
> > other Ant extensions.
>
> I read this as "I don't want the feature in core but
> provide hooks to
> make live easier for EasyAnt", right?
Pretty much, yeah, unless someone can make me see how
"phases" (by whatever nomenclature) are relevant to
basic Ant-fu. :)
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Stefan Bodewig <bo...@apache.org>.
On 2008-11-11, Matt Benson <gu...@yahoo.com> wrote:
> Personally I would prefer supporting arbitrary
> attributes on targets.
That would be easy to do.
> This would be less specific to EasyAnt and could have mileage for
> other Ant extensions.
I read this as "I don't want the feature in core but provide hooks to
make live easier for EasyAnt", right?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt phases
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> Hi all,
>
> EasyAnt has a concept named "phase" which is some
> special sort of
> target. The main differences:
>
> * is always empty
>
> * its depends list is open for other targets to
> modify, i.e. targets
> may add themselves as dependencies to a phase.
>
> It has been suggested to rename "phase" to
> "target-group".
>
> Without going into implementation details, do we
> want to add the
> concept itself to Ant's core?
>
> If we don't I'll volunteer to help the EasyAnt
> people to hook the
> concept into Ant without patching Ant itself.
>
Personally I would prefer supporting arbitrary
attributes on targets. This would be less specific to
EasyAnt and could have mileage for other Ant
extensions.
-Matt
> Stefan
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org