Steve Loughran wrote:
1. I'd worry that you are effectively defining a new language -a
functional one- inside ant.
2. it doesnt have to be ${}; we would be better using a new symbol
like x{}, though again, things will break and we will get accused of
having the perl attitude to obscure bits o
On Thu, 22 Jul 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> as Conor reminded us the last time we talked about this, he already
> added property evaluation to for Ant 1.4 .
> Non-issue, then.
Yep, I managed to overlook that Target#testIf/UnlessCondition expand
properties.
Stefan
gt; >
> > I am also thinking on Conditionals providing a subinterface that
> > allows simpler glueing into the evaluation engine. So we
> would be able
> > to say something like:
> >
> > if="${cond: $available.att("file",
> ${myFile}).att(&
Phil Weighill-Smith wrote:
XPath is a language that handles complex expressions that *can* include
document navigation and "query" paths but also contains a lot of other
capabilities (consider what you can do with expressions in XSLT: these
expressions use XPath with extension functions).
My sugges
type","file")}" or
> if="${cond: $available.file(myFile).type("file")}"
>
> or something like that. This will require us going ahead with addig
> roles to
> the context know what conditionals are out there.
>
> Comments,
roles to
the context know what conditionals are out there.
Comments, thrashing, refining, how to's?
Jose Alberto
> -Original Message-
> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
> Sent: 22 July 2004 12:22
> To: Ant Developers List
> Subject: Re: new Task subcl
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
[SNIP]
> > But if the same principles apply, would
> be restricted from
> > expression evaluation for the same reasons as it
> is restricted from
> > property evaluation, no?
>
> Probably yes. The only things where I see a
> technical reason are
> de
milar)?
Whatever expression language is decided on, I'd like to see
something very readable like:
- Original Message -
From: "Matt Benson" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, July 22, 2004 7:58 AM
Su
On Thu, 22 Jul 2004, Matt Benson <[EMAIL PROTECTED]> wrote:
> Doh, that's right back to THAT big argument again.
8-)
> But if the same principles apply, would be restricted from
> expression evaluation for the same reasons as it is restricted from
> property evaluation, no?
Probably yes.
Phil Weighill-Smith wrote:
My vote for a "language" within if/unless elements is to use XPath (1 or
2). Pretty powerful and standard within the XML domain! You could even
think of supporting path expressions that access the entities (targets,
properties, types etc.) within the current Ant build fil
On Thu, 22 Jul 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
>> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
>> Finally, it would even be possible to drop the delimiter and
>> evaluate the expression as an XPath instead of as a property
>> name if there are any "illegal" propert
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
[SNIP]
> if/unless on a task or a nested element of a task
> are normal
> attributes and as such get expanded. if/unless on
> doesn't
> get expanded.
>
Doh, that's right back to THAT big argument again.
But if the same principles apply, would b
> From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
>
> My vote for a "language" within if/unless elements is to use
> XPath (1 or 2). Pretty powerful and standard within the XML
> domain! You could even think of supporting path expressions
> that access the entities (targets, properties, ty
On Thu, 22 Jul 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> But if we tell people that in if/unless now you can put expressions
> and then give no implementation in core...
We already tell people they can plug in whatever kind of strange thing
they want into ${xyz} expansion - withou
On Thu, 22 Jul 2004, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Thu, 22 Jul 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>> Still, do if/unless get property expanded (do not remember
>> anymore).
>
> No, you are correct.
Well, unfortunately its worse.
if/unless on a task or a n
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Thu, 22 Jul 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
> >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> >>
> >> On Thu, 22 Jul 2004, Jose Alberto Fernandez
> >> <[EMAIL PROTECTED]> wrote:
> >>
> >> > As per if/unless i
My vote for a "language" within if/unless elements is to use XPath (1 or
2). Pretty powerful and standard within the XML domain! You could even
think of supporting path expressions that access the entities (targets,
properties, types etc.) within the current Ant build file and could
provide some su
On Thu, 22 Jul 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
>> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>>
>> On Thu, 22 Jul 2004, Jose Alberto Fernandez
>> <[EMAIL PROTECTED]> wrote:
>>
>> > As per if/unless itself, I really would like to explore
>> more what some
>> > peopl
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Thu, 22 Jul 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > As per if/unless itself, I really would like to explore
> more what some
> > people have suggested about having a richer language than just
> > set/unset.
>
>
On Thu, 22 Jul 2004, Jose Alberto Fernandez
<[EMAIL PROTECTED]> wrote:
> As per if/unless itself, I really would like to explore more what
> some people have suggested about having a richer language than just
> set/unset.
PropertyHelper?
IOW, I think we already have the infrastructure needed to
> From: Mike Jennings [mailto:[EMAIL PROTECTED]
>
> > Ok here is the argument about being not such a good idea
> (in general).
> > 1) For every contition you need to test in the whole of
> your buildfile
> > you need to come up with yet another property that will be use for
> > testing it.
>
> Ok here is the argument about being not such a good idea (in general).
> 1) For every contition you need to test in the whole of your buildfile
> you need to come up with yet another property that will be use for
> testing it.
>
> 2) Then you need to make sure that all your properties have been
> From: Mike Jennings [mailto:[EMAIL PROTECTED]
>
>
> Thanks again for the feedback! Both and have
> if="" and unless="" attributes. Is there any chance that
> these attributes will be changed or removed? Is there a
> consensus about if/unless handling in these components?
>
> Perhaps ther
> I knew.
> But there is the hierarchy-depth problematic.
> And if ALL tasks should have such a if/unless-handling the right place is
> inside
> oata.Task itself, so all tasks will have that implicit. And why only
tasks?
> Why
> not all ProjectComponents? But we havent any consensus about if/unless
Thanks for the feedback!
I was thinking more along the lines of:
public abstract class IfUnlessTask extends Task {
protected String ifCondition,unlessCondition;
public void setIf(String ifc) ...
public void setUnless(String unc) ...
protected boolean conditionsAreValid()...
public void
25 matches
Mail list logo
