Matt Benson wrote:
Stefan and I talked about doing one of these here:
http://marc.theaimsgroup.com/?l=ant-user&m=107487826503877&w=2
Peter and I each produced a different implementation. See
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26364
for our discussion. In the end Peter's changes are
probably more powerful than mine but his specific
implementation represents a paradigm shift, hence our
decision to start a thread devoted to the issue.
<mapper>s have always been specified via a <mapper> element and either a "type" or "classname" attribute, which actually specified an implementation of FileNameMapper. Peter's proposition allows to define the implementation type directly in types/defaults.properties, then nest these directly into the <mapper> element. In this way <mapper>s would/could look a lot more like <condition>s and <selector>s, especially when ref'd. Another note is that adding new core mappers would be a properties file (or other typedef) edit rather than a change to an EnumeratedAttribute. Finally, this allows more specialized attributes on mappers than just "to" and "from". So... does anyone have a problem with changing the recommended usage of <mapper>s while maintaining BC?
-Matt
__________________________________
This sounds good.
I do not know whether it is 100% related,
but there is an open bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3198 concerning the <javac/> task
in the case where the same source file is present in several source paths.
Will we be better fit to solve this problem with the new mapper infrastructure ?
Antoine
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
