Why: At the moment the value of an attribute is always expanded before it is passed to the element defining it (through setXXX). On the other hand nested text is passed unexpanded to the corresponding method (addText) and can be expanded explicitely by the implementor of the task/type. Tha't the reason why scripts can be passed as nested text without escaping the $ to $$ to avoid expressions being misunderstood as Ant properties. It would be nice to have the same possibility for attributes, so that i.e. short script expressions can be defined in there, too, without needing to escape them. Proposed solution: The solution, suggested by Jan Meterne months ago, is to let task/types define an optional method called through introspection, which returns the setXXX methods that receive the unexpanded parameter. Compatibility: This is backwars compatible as far as no task writer out there already defined some method like Method [] getUnexpandedAttrSetters() returning an array containing some of it's setXXX methods. Very, very unlikely :-). Stefano Marsili www.efanomars.net/pf
Created attachment 18663 [details] Patch to pass unexpanded attributes to tasks ** Sources ** IntrospectionHelper.java: - added method unexpandedAttributes(Object bean) returning the list of unexpanded attribute names RuntimeConfigurable.java: - changed maybeConfigure() to call replaceProperties() only if attribute not in the list (or the list is null) ProjectHelper.java: - same as RuntimeConfigurable.java I also patched this file's configure() method even though it is deprecated. My guess is that if there isn't a throw exception in it, it might be called. Since I was there I also changed the way replaceProperties is called (AFAIK it is needlessly cloning the project's properties, but maybe there is a reason for that). ** Tests ** CustomTasksTest.java: - just a quick superficial test to see whether it works. ** Note ** Modified and patched against latest 1.70alpha. Stefano Marsili
I would be very wary to introduce a way to have attributes which break the current behavior of always expanding properties. This to me breaks "the principle of least surprise" (http://en.wikipedia.org/wiki/Principle_of_least_astonishment). Unless we can find a "notation" that clearly indicates to the user unambiguously that a string won't be expanded, I'd probably -1 unexpanded attributes. I doubt we can find an acceptable notation that doesn't break BC, and in any case one can always use $$ to prevent the expansion. --DD