, 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 subclass
My vote for a language within if/unless elements is to use
XPath (1 or 2). Pretty
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
[mailto:[EMAIL PROTECTED]
Sent: 22 July 2004 12:22
To: Ant Developers List
Subject: Re: new Task subclass
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
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 target if/unless for Ant 1.4 .
Non-issue, then.
Yep, I managed to overlook that Target#testIf/UnlessCondition expand
properties.
Stefan
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
-Original Message-
From: Phil Weighill-Smith [mailto:[EMAIL PROTECTED]
Sent: 22 July 2004 12:22
To: Ant Developers List
Subject: Re: new Task subclass
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
I'm not sure it should be done via References, but I
agree that it
should be easy to do - and possible to do from
within the build file.
The examples we have in the sandbox all combine a
PropertyHelper with
a task that installs it. This works and would look
like
taskdef
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.
2) Then
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 do
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.
PropertyHelper?
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
people have suggested
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
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 itself, I really would like
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 nested
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 - without
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, types
--- 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
target doesn't
get expanded.
Doh, that's right back to THAT big argument again.
But if the same principles apply, target
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 property name
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 file
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, target would be restricted from
expression evaluation for the same reasons as it is restricted from
property evaluation, no?
Probably yes.
language is decided on, I'd like to see
something very readable like:
somecmd ifexp=${mode}=debug
/somecmd
- Original Message -
From: Matt Benson [EMAIL PROTECTED]
To: Ant Developers List [EMAIL PROTECTED]
Sent: Thursday, July 22, 2004 7:58 AM
Subject: Re: new Task subclass
--- Stefan
--- Stefan Bodewig [EMAIL PROTECTED] wrote:
[SNIP]
But if the same principles apply, target 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
depends
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 execute()
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
From: Mike Jennings [mailto:[EMAIL PROTECTED]
Thanks again for the feedback! Both target and fail 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 there
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
execute() {
if (!iuh.isValid) { return; }
}
}
Jan
-Ursprüngliche Nachricht-
Von: Mike Jennings [mailto:[EMAIL PROTECTED]
Gesendet am: Montag, 19. Juli 2004 15:30
An: [EMAIL PROTECTED]
Betreff: new Task subclass
Hi,
I was thinking
'if' and
'unless' parameters?
-Mike
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 19, 2004 10:49 PM
Subject: AW: new Task subclass
IMHO it doesnt make sense:
1. We have no real consense how we want handle conditional tasks
- for all tasks
Hi,
I was thinking that all of the core tasks that have if= and unless= attributes
could have a common ancestor which would be a subclass of
org.apache.tools.ant.Task
Is there an obvious reason to not do this? If this makes sense I can code it up
and submit it.
-Mike
29 matches
Mail list logo
