> From: Martijn Kruithof [mailto:[EMAIL PROTECTED] > Is this te direction we are going with "roles": > > <project name="foo" default="bar" > xmlns:co="ant:condition" > xmlns:set="ant:resourceselector"> > > <resourcecollection id="blah"> > <set:and> > <set:files dir="foo" name="**/*.java"/> > <set:date select="newer" date="2005/04/15"/> > </set:and> > </resourcecollection> > > </project>
Whao, I'm getting this email exchange out-of-order! Weird. Martijn, Matt, the example above would be necessary if and only if <resourcecollection> only had a add(ResourceSelector). In practice, we'll likely have specialized addAnd(ResourceSelector) and co so that if can be written just: > <resourcecollection id="blah"> > <and> > <files dir="foo" name="**/*.java"/> > <date select="newer" date="2005/04/15"/> > </and> > </resourcecollection> The NS prefix would be necessary only in 3rd party custom task that only have a add(ResourceSelector) method and none of the specialized add methods. And even then, the 3rd party can still decide to add the specialized adds. So really the need to NS prefix roles appears in specific cases only: 1) In build files where XML namespaces are used and 'welcome'. 2) When there's a possible ambiguity with another role, for example in a class with both a add(Condition) and a add(FileSelector). I want to stress that we're not forcing everyone to use XML namespaces if we create these role AntLibs. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
