Bug 40140 - Let task/types receive unexpanded attribute(s)
Summary: Let task/types receive unexpanded attribute(s)
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.7.0
Hardware: Other Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Keywords: PatchAvailable
Depends on:
Reported: 2006-07-31 05:51 UTC by Stefano Marsili
Modified: 2009-07-31 06:45 UTC (History)
0 users

Patch to pass unexpanded attributes to tasks (9.64 KB, patch)
2006-07-31 05:55 UTC, Stefano Marsili
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefano Marsili 2006-07-31 05:51:00 UTC
  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.
  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
Comment 1 Stefano Marsili 2006-07-31 05:55:28 UTC
Created attachment 18663 [details]
Patch to pass unexpanded attributes to tasks

** Sources **
 - added method unexpandedAttributes(Object bean)
   returning the list of unexpanded attribute names

 - changed maybeConfigure() to call replaceProperties()
   only if attribute not in the list (or the list is null) 

 - 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 **
  - just a quick superficial test to see whether it works.

** Note **
Modified and patched against latest 1.70alpha.

Stefano Marsili
Comment 2 Dominique Devienne 2006-07-31 12:56:56 UTC
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" 

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