On 29 July 2011 12:35, Benson Margulies <bimargul...@gmail.com> wrote: > I'm in favor of the policy (since I suggested it), that maven 3.0.X
I think that requires at least a minor bump I would not be happy with classing those as a patch bump > can deliver pom XSD 4.0.Y, where the changes the the XSD are proven to > be harmless to popular old versions and common sense characterizes > them as unlikely to blow anything up. I submit that adding some > inheritance control attributes would come under that rubric. > > Do we need to vote this, or otherwise clarify consensus or the lack > thereof? Does anyone hate it? > > On Fri, Jul 29, 2011 at 4:26 AM, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: >> How about coming at this from a different track... >> >> <scm>scm:parent:/path/in/parent</scm> >> >> that is an SCM that is the same as parent with a path in the parent. >> >> the parent scm provider would look up the parent's scm and could use >> some rules to derive the effective path, acting like a delegate and >> giving us the correct path. >> >> It does mean that unless <prerequ><maven>3.1</maven></prerequ> users >> would have to specify the scm in all initial child modules. >> >> On 29 July 2011 08:39, Mark Struberg <strub...@yahoo.de> wrote: >>> 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 >>> >>> >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
