Summary: | Let task/types receive unexpanded attribute(s) | ||
---|---|---|---|
Product: | Ant | Reporter: | Stefano Marsili <efanomars> |
Component: | Core | Assignee: | Ant Notifications List <notifications> |
Status: | NEW --- | ||
Severity: | enhancement | Keywords: | PatchAvailable |
Priority: | P2 | ||
Version: | 1.7.0 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | Linux | ||
Attachments: | Patch to pass unexpanded attributes to tasks |
Description
Stefano Marsili
2006-07-31 05:51:00 UTC
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 |