> Cool, but you'll have to wait a bit for me to integrate this if you
> don't have an accompanying test.
Hmm, I thought there already was a ProjectInheritanceTest. It does pass this test...
But I understand your point. No problem. I am actually quite impressed with the quick
feeback here on the user list.
>> Also included in the patch is an alternative way to specify custom
>> properties in the project pom. Currently the behavior is the following:
>> ...
>> <properties>
>> <someproperty>value</someproperty>
>> </properties>
>> ...
>> The patch adds support for the following syntax as well:
>> ...
>> <properties>
>> <property name="someproperty" value="value"/>
>> </properties>
>> ...
>> I added this because I saw a case where my property name might not be a
>> valid XML element name. The patch is backwards compatable with the
>> existing syntax.
> You have a specific example? We've never used attributes. This started
> when we weren't using betwixt but the xo mapper which used attributes as
> meta information for mapping. Unless you have a specific example of an
> property name that won't work I won't be integrating that behaviour.
I have two arguments against the current syntax. One, it makes it harder to validate
your pom since the property name is the element name, you'll basically have an anyElem
rule in the xsd. Two, the property name must be of the form:
Name ::= (Letter | '_' | ':') (NameChar)*
NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender
This specifically rules out property names that start with a digit, or contains
unicode chars. Also if your property has a ':' in its name, the parser will confuse it
with a QName. Of course this is nit-picky, but I was really trying to appease my anal
xml aesthetic. Don't dot-form property names look ugly in the current form :)
<some.dot.property>value</some.dot.property>
If the problem is just with having attribute form xml, then I could submit a patch
with the following syntax:
<properties>
<property>
<name>someproperty</name>
<value>propertyValue</value>
</property>
</properties>
There is a small code benefit in the submitted patch. BaseObject is cleaner in the
sense that it doesn't have to maintain two property lists to appease betwixt. So
there's just getProperties():Map and setProperty(name,value). The digester rules added
in MavenUtils correctly resolves the properties, and properties don't have to be added
in "name:value" combined form. I assumed this was a hack for betwixt, but maybe there
were other reasons for this...
In any case, it's not the end of the world if this stuff doesn't make it in.
Regards,
--mike
