On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] wrote:
2008/11/20 Stefan Bodewig [EMAIL PROTECTED]:
On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] 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
2008/11/21 Stefan Bodewig [EMAIL PROTECTED]:
On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] wrote:
2008/11/20 Stefan Bodewig [EMAIL PROTECTED]:
On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] wrote:
- What about the if/unless?
This would be pretty hard to implement as you saw yourself
2008/11/19 Bruce Atherton [EMAIL PROTECTED]:
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
On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] 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
On Wed, Nov 19, 2008 at 11:19 PM, Stefan Bodewig [EMAIL PROTECTED] wrote:
On 2008-11-19, Bruce Atherton [EMAIL PROTECTED] 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
2008/11/20 Stefan Bodewig [EMAIL PROTECTED]:
On 2008-11-20, Gilles Scokart [EMAIL PROTECTED] 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
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
On 2008-11-19, Bruce Atherton [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]
On Fri, Nov 14, 2008 at 7:55 AM, Stefan Bodewig [EMAIL PROTECTED]
wrote:
On
Sorry i'm missed this mail
2008/11/14 Gilles Scokart [EMAIL PROTECTED]
2008/11/13 Gilles Scokart [EMAIL PROTECTED]:
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
On Tue, Nov 18, 2008 at 10:07 AM, Jean-Louis BOUDART
[EMAIL PROTECTED] 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/
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
On 2008-11-18, Jean-Louis BOUDART [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
On 2008-11-18, Jean-Louis BOUDART
[EMAIL PROTECTED] 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
On 2008-11-18, Jean-Louis BOUDART [EMAIL PROTECTED] 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
On 2008-11-18, Matt Benson [EMAIL PROTECTED] 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
-
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 /
On 2008-11-14, Remie Bolte [EMAIL PROTECTED] 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
On 2008-11-13, Matt Benson [EMAIL PROTECTED] wrote:
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
On 2008-11-11, Matt Benson [EMAIL PROTECTED]
wrote:
Personally I would prefer supporting arbitrary attributes on
targets.
This would be less specific to EasyAnt and could have mileage for
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
2008/11/13 Gilles Scokart [EMAIL PROTECTED]:
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
On 2008-11-13, Dominique Devienne [EMAIL PROTECTED] 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
On Fri, Nov 14, 2008 at 7:55 AM, Stefan Bodewig [EMAIL PROTECTED] wrote:
On 2008-11-13, Dominique Devienne [EMAIL PROTECTED] 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.
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
On 2008-11-11, Matt Benson [EMAIL PROTECTED]
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
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
2008/11/13 Stefan Bodewig [EMAIL PROTECTED]:
On 2008-11-12, Remie Bolte [EMAIL PROTECTED] 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
On Thu, Nov 13, 2008 at 1:08 PM, Bruce Atherton [EMAIL PROTECTED] 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
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
On Thu, Nov 13, 2008 at 1:44 PM, Gilles Scokart [EMAIL PROTECTED] 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
Here is some additional information on EasyAnt phase concept
http://easyant.abrm.info/trac/wiki/tasks/phase
On Wed, Nov 12, 2008 at 6:00 AM, Remie Bolte [EMAIL PROTECTED] 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
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.
Remie Bolte [EMAIL PROTECTED] 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
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
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
On 2008-11-12, Remie Bolte [EMAIL PROTECTED] 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
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.
Jeffrey E. (Jeff) Care
[EMAIL PROTECTED]
IBM WebSphere Application Server
WAS Release Engineering
From:
Stefan Bodewig [EMAIL PROTECTED]
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
On Tue, Nov 11, 2008 at 5:25 AM, Stefan Bodewig [EMAIL PROTECTED] 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
--- Stefan Bodewig [EMAIL PROTECTED] 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.
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 [EMAIL PROTECTED] wrote:
Hi all,
EasyAnt has a concept named phase which is some special sort of
target.
On 2008-11-11, Remie Bolte [EMAIL PROTECTED] 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
On 2008-11-11, Matt Benson [EMAIL PROTECTED] 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
Remie Bolte [EMAIL PROTECTED] 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
44 matches
Mail list logo
