You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefano Marsili <rs...@yahoo.com> on 2006/05/13 20:06:52 UTC

Suppress RelaceProperties in Task

Hi! I'm posting in ant-dev rather then ant-user
because I fear my question needs a deep 
understanding of the ant implementation.

I made a class that can act both as a Task and a 
passive ProjectComponent. That is, if defined in
a target or as a direct child of <project> it's execute()
method is called, if defined as a nested element not.

The problem is that when acting as a task the attributes
are evaluated if they contain property references (${x}), 
when acting as a passive element not (you'd have to do
it explicitely by calling replaceProperties()).

Is it possible to avoid property replacement in the task 
attributes in a clean and safe way?
I wanted to try to override Task.maybeConfigure() but
there are the RuntimeConfigurable and UnknownElement
I'm not familiar with.

Sorry if it's a stupid question or I oversaw something evident.

Thanks,
Stefano Marsili




		
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2ยข/min or less.

Re: Suppress RelaceProperties in Task

Posted by Stefano Marsili <rs...@yahoo.com>.
> FWIW, text doesnt get expanded, and its a big source of problems as 
> people (including ant developers) are always forgetting to expand them.

I don't think it would worsen the problem, it might even be one more
place in the code to make task writers aware of the pitfall.

I also think that in a well written task the user shouldn't even 
be aware of it. But there are special cases it might be useful.
Examples:
- The attribute represents an expression with an ant like syntax 
  you don't want to fill with '$$'.
- You want to handle the attribute somehow before calling 
  ReplaceProperties yourself.
- You want to implement lazy evaluation.

> If you take the stuff as nested text you can bypass the expansion.

I hadn't thought about it, thanks! I already have implemented a 
"::noexpansion::" solution in a custom PropertyHelper ... 
but this seems easier, I'll definitely give it a try.

Stefano Marsili


		
---------------------------------
Get amazing travel prices for air and hotel in one click on Yahoo! FareChase 

Re: Suppress RelaceProperties in Task

Posted by Steve Loughran <st...@apache.org>.
Stefano Marsili wrote:
> Sorry, I oversaw the fact that replaceProperties(...) is called for 
> attributes of both tasks and nested elements (it would have been 
> a strange asymmetry). I just tested it the wrong way (stupid!).
> 
> But still, wouldn't it be nice for a Task implementor to have
> the possibility to turn off property replacement for some 
> attributes? As long as it is documented it should be ok.

makes things complex. how would we indicate it? Can't use java5 
attributes so that leaves the feared XML descriptor or a new naming 
scheme for introspection, like noExpandsSetMyAttribute

FWIW, text doesnt get expanded, and its a big source of problems as 
people (including ant developers) are always forgetting to expand them.

> 
> AFAIK at the moment, to implement this I have to install 
> my own main PropertyHelper overriding replaceProperties(string) 
> and catch expressions I don't want to be parsed with a prefix,
> something like ":noparsing:$$xxx${${}yyy".

If you take the stuff as nested text you can bypass the expansion.

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


Re: Suppress RelaceProperties in Task

Posted by Stefano Marsili <rs...@yahoo.com>.
Sorry, I oversaw the fact that replaceProperties(...) is called for 
attributes of both tasks and nested elements (it would have been 
a strange asymmetry). I just tested it the wrong way (stupid!).

But still, wouldn't it be nice for a Task implementor to have
the possibility to turn off property replacement for some 
attributes? As long as it is documented it should be ok.

AFAIK at the moment, to implement this I have to install 
my own main PropertyHelper overriding replaceProperties(string) 
and catch expressions I don't want to be parsed with a prefix,
something like ":noparsing:$$xxx${${}yyy".

Stefano Marsili


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