gnah sorry :( I explicitly tested the schema validation, but obviously using a new tool (I'm new to macs...) at 3 o clock in the morning isn't producing reliable results :/
But your idea with the XSD-4.0.1 sound really great. Almost too good to believe! That would probably allow us to implement most of the new features like mixins and stuff _without_ getting incompatible. Maybe we could not implement all the new stuff, but it's worth thinking about it. Otoh I'm not sure if such a change should be done in a bugfix release. Or better said: I'm pretty sure that we should _not_ do such a change in a bugfix release ;) LieGrue, strub --- On Fri, 7/29/11, Benson Margulies <bimargul...@gmail.com> wrote: > From: Benson Margulies <bimargul...@gmail.com> > Subject: Re: [DISCUSS] SCM child-project URL composition > To: "Maven Developers List" <dev@maven.apache.org> > Date: Friday, July 29, 2011, 2:01 AM > I have some perhaps minor bad news > about attributes. > > Attributes on the <url/> element won't validate > against the current > schema. I had hoped to discover otherwise, but no such > luck. > > The combine.children trick passes because it is inside of > the 'any' > inside the plugin configuration. > > I claim that the following is tolerable from a > compatibility standpoint: > > 1) create a 4.0.1 XSD file that adds the necessary > xs:anyAttribute (or > specific attributes, if you prefer) to the <url/> > element. > > 2) Change default archetypes and the release plugin and > friends to add > this schema instead of the 4.0.0 schema. > > In other words, Mark's experiments show that, in > *practical* terms, > adding the attributes works. That leave the question of > programs that > actually pay attention to the schema itself. The only bad > case would > be some program out there which for some reason always > validates > against the 4.0.0 schema even if the schema declared at the > top is > 4.0.1. I don't believe in this. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
