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
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
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 wh
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 empt
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
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,
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
completel
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 B
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
--
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
--- 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 wh
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
>
> > 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 app
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
>
> unless="skip.test"/>
>
> ...
>
>
> By typing "ant test" you will execute ALL
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 th
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 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 b
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
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 bas
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 ha
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.:
>
>
>
>
>
As EasyAnt's implementation stands, phases *are* targets, this means
(or should mean)
Perhaps it is possible to create a dependency between phases, and
additionally give targets the possibility to depend on a phase i.e.:
(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 f
On 2008-11-13, 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.
I wasn't advocating we change the current behavior, Ant's own build
file relies on it in much the same way as
>
Here is some additional information on EasyAnt phase concept
http://easyant.abrm.info/trac/wiki/tasks/phase
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
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: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:
>
> ...
> ...
>
> Whether or not "clean" is a dependency of "compil
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
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:
...
...
Whether or not "clean" is a dependency of "compile" depends on the
context "compile" is executed in. Now, it is possible to work around
--- 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
> > ot
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 "
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 desi
"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,
> 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 order
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 t
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,
"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:
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
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
as a template for Java compilation. This one gets imported or
incl
--- 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 dependenci
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
> ta
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
-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
__
43 matches
Mail list logo
