On 2011-07-18, Jochen Wiedmann wrote:
> I don't think the antlib has the same support for custom license
> matchers than the Maven plugin does.
Quite possible. Let me describe what is possible in the Antlib and
we'll go from there.
In Ant you can define any class you want as a type, so
> <customLicenseMatcher class="com.foo.MyCustomLicenseMatcher">
> <unknownProperty>34098</unknownProperty>
> <someOtherUnknownProperty>true</someOtherUnknownProperty>
> <customLicenseMatcher>
becomes
<typedef name="mymatcher"
classname="com.foo.MyCustomLicenseMatcher"/>
and if the class uses Ant's conventions for setters and adders like say
public void setUnknownProperty(int i) { }
<mymatcher unknownProperty="34098"/>
is a valid snippet of Ant that defines an instance of said class and
sets the property.
The report task in the RAT Antlib accepts any defined Ant type as nested
element that implements IHeaderMatcher (and any type that implements
ILicenseFamily for custom licenses as well). This is what the
void add(InterfaceType) methods do in Ant.
This the comes down to
<typedef name="mymatcher"
classname="com.foo.MyCustomLicenseMatcher"/>
<rat:report ...>
<mymatcher unknownProperty="34098"/>
</rat:report>
> However, I haven't got an idea how to handle such "unknown properties"
> in Ant.
I hope it has become a bit clearer.
Stefan
PS: I could also have used componentdef instead of typedef so
<mymatcher> would only be allowed to appear as nested element of another
element and not at the top level.
PPS: The Antlib uses this mechanism itself, the "known" licenses and
matchers like <asl20> are defined via typedef inside antlib.xml. There
is no single hard-coded license or matcher inside the Antlib.
