I was going through the Xmlc taskdef to update the docs as requested on the
list earlier. However, I saw some inconsistencies. One that I'd like to
change, but might affect some people, is changing the "force" attribute to
take an Xmlc.BooleanType like the other boolean attributes do instead of a
String. This shouldn't normally affect anyone if they were using
true/false values and, in fact, this change will now allow for yes/no
values to be valid as well (as they weren't recognized before). However,
any other string will cause an error in the build. This affected the
BarracudaMVC build because ${xmlc.force} was being used, but not always
present when running the task, so it would error out saying that
"${xmlc.force}" is not a valid value for the "force" attribute. This is
simple to correct by making sure a default value for ${xmlc.force} is
always set to true/false or yes/no (if the optional force attribute is
actually used) and allow for overriding in a properties file.
I'm wondering if anyone else has a use-case where this change would bite
them like it did the Barracuda build. I can change it back to taking a
String rather than the Xmlc.BooleanType if need be. Community
decides. Speak up.
Jake
| 