no conditional attribute

[Kev Jackson <fo...@gmail.com>]

Hi,

I know that this has come up before but I've just finally seen why  
it's so damn useful - <echo message="blah" level="verbose" unless=$ 
{property.set}/>

I've just run into this now trying to help the BSF guys getting a  
release candidate out and the build.xml needed a bit of work and this  
would make so *much* easier.

Thoughts?
Kev
--
"I call it the State where everyone, good or bad, is a poison- 
drinker: the State where universal slow suicide is called - life" -  
Friedrich Nietzsche


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Stefan Bodewig <bo...@apache.org>]

On Tue, 15 Aug 2006, Matt Benson <gu...@yahoo.com> wrote:

> I forgot about mutant vs. Myrmidon, was thinking of
> Myrmidon when you said mutant.  I reread Conor's blog
> post on this and you are correct.  Looking for any old
> code but can't find it yet.

http://svn.apache.org/repos/asf/ant/core/branches/ANT_14_BRANCH/proposal/mutant/

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Matt Benson <gu...@yahoo.com>]

--- Dominique Devienne <dd...@gmail.com> wrote:

> > > I'm still wondering about adding arbitrary
> "aspect"
> > > attributes to tasks, as Mutant had.
> >
> > Sounds interesting.  I wasn't around while Mutant
> was
> > under development; how can I learn more?
> 
> I barely was myself. Mutant and Myrmydon were two
> Ant 2.0 competing
> proposal. They were voted down eventually. I believe
> Mutant was
> Conor's brain child, so better ask him ;-) --DD

I forgot about mutant vs. Myrmidon, was thinking of
Myrmidon when you said mutant.  I reread Conor's blog
post on this and you are correct.  Looking for any old
code but can't find it yet.  Conor?

-Matt

> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Dominique Devienne <dd...@gmail.com>]

> > I'm still wondering about adding arbitrary "aspect"
> > attributes to tasks, as Mutant had.
>
> Sounds interesting.  I wasn't around while Mutant was
> under development; how can I learn more?

I barely was myself. Mutant and Myrmydon were two Ant 2.0 competing
proposal. They were voted down eventually. I believe Mutant was
Conor's brain child, so better ask him ;-) --DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Stefan Bodewig <bo...@apache.org>]

On Wed, 16 Aug 2006, Martijn Kruithof <jm...@kruithof.xs4all.nl> wrote:
> Conor MacNeill schreef:
> 
>>1. Just adding all the logic tasks everyone uses anyway :-)
>>2. Adding if/unless processing to Task
>>3. Implementing aspect style interface(s) and providing an if/unless
>>aspect.

[SNIP]

> I think I'd prefer option 3 over option 1, and do not like option 2
> as much.

Same here.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Matt Benson <gu...@yahoo.com>]

--- Martijn Kruithof <jm...@kruithof.xs4all.nl> wrote:

> Conor MacNeill schreef:
> 
> >1. Just adding all the logic tasks everyone uses
> anyway :-)
> >2. Adding if/unless processing to Task
> >3. Implementing aspect style interface(s) and
> providing an if/unless aspect.
> >
> >Thoughts?
> >  
> >
> Treating the options in inverse order.
> I think that option 3 is most versatile and seems
> scalable to other 
> aspects, for instance the logging level.
> I think that option 2 will bite us, as it introduces
> the logic in the 
> task, and does not seem scalable when other logic is
> desired. (This does 
> not mean I am in favour of adding if/unless to
> specific tasks!)
> Option 1 seems workable and is scalable as well, and
> seems simpler than 
> option 3.
> 
> I think I'd prefer option 3 over option 1, and do
> not like option 2 as much.
> 
> Option 1 is covered by ant-contrib, so the added
> value of doing it as 
> well is limited.
> 

Like Martijn, DD, and Conor (presumably since mutant
purportedly had something of the kind), I like option
3, though I haven't given it enough thought to know
how to implement it.

FWIW,
Matt

> 
> Martijn
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Martijn Kruithof <jm...@kruithof.xs4all.nl>]

Conor MacNeill schreef:

>1. Just adding all the logic tasks everyone uses anyway :-)
>2. Adding if/unless processing to Task
>3. Implementing aspect style interface(s) and providing an if/unless aspect.
>
>Thoughts?
>  
>
Treating the options in inverse order.
I think that option 3 is most versatile and seems scalable to other 
aspects, for instance the logging level.
I think that option 2 will bite us, as it introduces the logic in the 
task, and does not seem scalable when other logic is desired. (This does 
not mean I am in favour of adding if/unless to specific tasks!)
Option 1 seems workable and is scalable as well, and seems simpler than 
option 3.

I think I'd prefer option 3 over option 1, and do not like option 2 as much.

Option 1 is covered by ant-contrib, so the added value of doing it as 
well is limited.


Martijn

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Conor MacNeill <co...@apache.org>]

Dominique Devienne wrote:
> 
> PS: Note that adding if/unless to <sequential> gives an implicit
> <if>-like. I like it myself, and even proposed to it, but this was
> voted down by the commiter that left when @author tags were removed
> (don't recall his name. He did the property hook, and was a Tomcat
> commiter).
> 

That would be Costin Manolache.

Conor


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Dominique Devienne <dd...@gmail.com>]

On 8/16/06, Peter Reilly <pe...@gmail.com> wrote:
> I think that we should go for 2) adding if/unless to all tasks.
> It should have the same support as the if/unless in targets.
> I do not see the need for more complicated condition support
> (at least at the moment).

I would prefer 3. myself (aspect-style interface), for the reason that
I think we can solve the condition-support-for-datatypes issue you
mention.

The way I see it, we should not implement condition-aspects at
execution time, but at *configure* time. By that I mean when the
UnknownElements are turned into actual instances of the right
data-type, which unless I'm mistaken is right before the task
executes. What I envision are namespaced-attributes on any
non-<target> or <project> elements that make these elements
"disappear".

It's a bit akin to the UE processing MacroDef performs in fact.

Another reason is that I like my Ant to be extendeable, and the
aspect-approach give me that, to add ubiquitous access to ifTrue, os,
bshIf, etc... inline conditions.

If this doesn't fly, then I'd settle for 1. + 2., or just 2. Thanks, --DD

PS: Note that adding if/unless to <sequential> gives an implicit
<if>-like. I like it myself, and even proposed to it, but this was
voted down by the commiter that left when @author tags were removed
(don't recall his name. He did the property hook, and was a Tomcat
commiter).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Peter Reilly <pe...@gmail.com>]

I think that we should go for 2) adding if/unless to all tasks.
It should have the same support as the if/unless in targets.
I do not see the need for more complicated condition support
(at least at the moment).

There would be some snags (what about tasks that do
not derive from Task, what about tasks that already provide
if and unless attributes), however I feel that the benefits far
outweigh the drawbacks.

Not that the problem with condition support for datatypes is
a far harder problem to solve as the tasks themselves do
the processing of the datatypes.

Peter

On 8/16/06, Conor MacNeill <co...@apache.org> wrote:
>
> I'm pretty much in agreement with Stefan.
>
> If if/unless is going to be in some tasks, it should be in all. It
> reminds me of a principle from one of my old textbooks:
>
> Regularity Principle:
>
> Regular rules, without exceptions, are easier to learn, use, describe
> and implement.
>
> Once we go down the if/unless path, we have to think about what we
> should *not* put in the common behaviour of all tasks.
>
> Anyway, if we do provide it, I think we should write it once and not in
> every task. I'd say we need to decide between:
>
> 1. Just adding all the logic tasks everyone uses anyway :-)
> 2. Adding if/unless processing to Task
> 3. Implementing aspect style interface(s) and providing an if/unless
> aspect.
>
> Thoughts?
> Conor
>
> Stefan Bodewig wrote:
> >
> > For a long time I've taken the more extreme "all tasks or no task"
> > position on this 8-)
> >
> > Why would we want to add conditional attributes to echo (or
> > sequential) and not to copy?
> >
> > This leads to "wouldn't a nested condition be more expressive than
> > if/unless attributes" which then makes me think that adding an if task
> > would be cleaner.  Once I arrive there I start to feel uncomfortable.
> >
> > 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: no conditional attribute

[Conor MacNeill <co...@apache.org>]

I'm pretty much in agreement with Stefan.

If if/unless is going to be in some tasks, it should be in all. It
reminds me of a principle from one of my old textbooks:

Regularity Principle:

Regular rules, without exceptions, are easier to learn, use, describe
and implement.

Once we go down the if/unless path, we have to think about what we
should *not* put in the common behaviour of all tasks.

Anyway, if we do provide it, I think we should write it once and not in
every task. I'd say we need to decide between:

1. Just adding all the logic tasks everyone uses anyway :-)
2. Adding if/unless processing to Task
3. Implementing aspect style interface(s) and providing an if/unless aspect.

Thoughts?
Conor

Stefan Bodewig wrote:
> 
> For a long time I've taken the more extreme "all tasks or no task"
> position on this 8-)
> 
> Why would we want to add conditional attributes to echo (or
> sequential) and not to copy?
> 
> This leads to "wouldn't a nested condition be more expressive than
> if/unless attributes" which then makes me think that adding an if task
> would be cleaner.  Once I arrive there I start to feel uncomfortable.
> 
> 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: no conditional attribute

[Stefan Bodewig <bo...@apache.org>]

On Tue, 15 Aug 2006, Dominique Devienne <dd...@gmail.com> wrote:
>> I know that this has come up before but I've just finally seen why
>> it's so damn useful - <echo message="blah" level="verbose" unless=$
>> {property.set}/>
> 
> Well, I've been a proponent of this for a long time,

For a long time I've taken the more extreme "all tasks or no task"
position on this 8-)

Why would we want to add conditional attributes to echo (or
sequential) and not to copy?

This leads to "wouldn't a nested condition be more expressive than
if/unless attributes" which then makes me think that adding an if task
would be cleaner.  Once I arrive there I start to feel uncomfortable.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Matt Benson <gu...@yahoo.com>]

--- Dominique Devienne <dd...@gmail.com> wrote:

> > I know that this has come up before but I've just
> finally seen why
> > it's so damn useful - <echo message="blah"
> level="verbose" unless=$
> > {property.set}/>
> 
> Well, I've been a proponent of this for a long time,
> and I coded up my
> own <bm:echo> with conditions a long time ago, which
> also displayed
> nicely formatted paths and propertysets. I was using
> it to display
> diagnostics info specific to our builds, without
> having to resort to
> -verbose, which spews out too much unrelated
> material. One had to do
> -Dverbose=true, and my conditions were
> ifTrue="${verbose}".
> 
> All that to say that I'm +1. I don't recall who was
> against ;-) --DD

Either way, aren't universal if/unless more
to-the-point here, notwithstanding that someone was
against them as well?

> 
> PS: I also had a <bm:sequential> with the same
> conditions, as well as
> several other custom tasks with these conditions
> (if/unless/ifTrue/unlessTrue/os/osFamily/bshIf). I'm
> still wondering
> about adding arbitrary "aspect" attributes to tasks,
> as Mutant had.
> 

Sounds interesting.  I wasn't around while Mutant was
under development; how can I learn more?

-Matt

>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: no conditional attribute

[Dominique Devienne <dd...@gmail.com>]

> I know that this has come up before but I've just finally seen why
> it's so damn useful - <echo message="blah" level="verbose" unless=$
> {property.set}/>

Well, I've been a proponent of this for a long time, and I coded up my
own <bm:echo> with conditions a long time ago, which also displayed
nicely formatted paths and propertysets. I was using it to display
diagnostics info specific to our builds, without having to resort to
-verbose, which spews out too much unrelated material. One had to do
-Dverbose=true, and my conditions were ifTrue="${verbose}".

All that to say that I'm +1. I don't recall who was against ;-) --DD

PS: I also had a <bm:sequential> with the same conditions, as well as
several other custom tasks with these conditions
(if/unless/ifTrue/unlessTrue/os/osFamily/bshIf). I'm still wondering
about adding arbitrary "aspect" attributes to tasks, as Mutant had.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org