I guess it all depends on the question of whether we wish to link POM versions to Maven releases. I think, I'm being swayed and I agree it's cleaner to link them....
<thinking some more> Ok, I think I've realized what the problem is: We are developing 1.0-RC1 on HEAD. This is the main problem. Normally here's how I would expect development to work: - HEAD always contains latest development for the *next* release (that would be 1.1-SNAPSHOT for us) - Once a beta is released, CVS is branched (that would be MAVEN_1_0_BRANCH for us) and bug fixing happens on that branch while development for the next release continues on HEAD. For us the beta period has lasted too long but we could say that RC goes into a branch. Should this happen (i.e. move RC1 to a branch and start 1.1 dev on HEAD) then I'm happy to roll back all my changes related to POM4 and commit them on HEAD (1.1-SNAPSHOT). What do you say? Thanks -Vincent > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 20 November 2003 09:38 > To: 'Maven Developers List' > Subject: RE: [VOTE] Make groupId mandatory for POM version 4? > > Hi dIon, > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: 20 November 2003 09:28 > > To: Maven Developers List > > Subject: RE: [VOTE] Make groupId mandatory for POM version 4? > > > > I *really* don't wont a POM change between an RC and a 1.0 release. > > It's not a POM change as nothing is changed from POM3 and we're not > telling users to switch to POM4. Ok, let me explain the little that was > changed and you'll be able to comment on it: > > 1/ modified marshaller/unmarshaller to support top level <type> element. > That doesn't change any existing code > > 2/ modified marshaller/unmarshaller to support top level <version> > element (in addition to <currentVersion>, not touched) > > 3/ modified marshaller/unmarshaller to support top level <artifactId> > element (in addition to <id>, not touched) > > 4/ renamed maven-project.xsd to maven-project-3.xsd. This is to allow > easy migration to a new POM > > 5/ created a new maven-project-4.xsd (for POM4). > > 6/ modified pom:validate goal to check for valid POM versions. It > currently checks for either POM3 or POM4 > > 7/ modified pom:validate goal to support different POM versions. It does > this by validation maven-project-${pom.pomVersion}.xsd > > That's all I did and I don't believe it can cause any trouble. What I > would like to continue doing is: > > 8/ modify the marshaller/unmarshaller to support top level > <compatibilities> elements. BTW, this was discussed on IRC and on the > maven list I believe. I'll reopen the discussion before doing anything > as you were not here at that time and maybe not enough persons have > commented on it (AFAIR, Jason, Bob and me were ok on it). > > 9/ modify the multichanges plugin to add href links to the generated > report (for POM4 only as it requires info from <type>). > > Could you please answer telling me if you think some of these steps > should be rolled back and whether you believe it is ok for me to > continue with 8/ and 9/ (provided we get an agreement from you on 8/)? > > Thanks > -Vincent > > > -- > > dIon Gillard, Multitask Consulting > > Blog: http://blogs.codehaus.org/people/dion/ > > > > > > > > "Vincent Massol" <[EMAIL PROTECTED]> wrote on 20/11/2003 07:04:25 > PM: > > > > > Actually, that's not exactly true. I have already put POM v4 stuff > in > > > CVS. However, it's completely transparent to POM3 users and I do > agree > > > that we must provide 100% POM3 compatibility for 1.0. > > > > > > Here's what I would like to do. Please provide input on whether you > > > think it's acceptable or not. > > > > > > 1/ Continue to add the <compatibilities> stuff in POM4's XSD file > and in > > > the marshaller/unmarshaller > > > > > > 2/ All plugins should stay compatible with POM3 for now. In the > > > multichanges plugin, I'd like to add a feature: create an href link > to > > > the plugin distributable files. I will need to use the new <type> > > > element, available only in POM4. Thus the multichanges plugin will > not > > > have links when projects are using POM3 and will have links if > projects > > > are using POM4. In this manner it remains completely compatible with > > > POM3 while providing additional features for POM4. This should be a > rule > > > that all plugins need to be friendly with POM3. > > > > > > 3/ The website xdoc reference guide needs to be revisited to explain > > > POM3/POM4 and explain the differences. We have 2 options: > > > - one menu item for POM3 and another one for POM4 > > > - a single page for both POMs but explaining the differences where > the > > > 2 POMs diverge. > > > I think I'd prefer the first option. It should clearly be stated > that > > > POM3 is currently the officially released POM and that Maven 1.0 is > 100% > > > compatible with it. > > > > > > 4/ I've created a wiki page to describe the differences between > POM3's > > > XSD and POM4's XSD: http://wiki.codehaus.org/maven/Pom4vsPom3 > > > > > > Comments? > > > > > > Thanks > > > -Vincent > > > > > > > -----Original Message----- > > > > From: Brett Porter [mailto:[EMAIL PROTECTED] > > > > Sent: 18 November 2003 22:55 > > > > To: 'Maven Developers List' > > > > Subject: RE: [VOTE] Make groupId mandatory for POM version 4? > > > > > > > > My understanding is 1.1, as to my knowledge there has been no > handling > > > put > > > > into CVS yet. > > > > > > > > We must retain full v3 compatibility for 1.0 at the very least. > > > > > > > > Cheers, > > > > Brett > > > > > > > > > -----Original Message----- > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, 19 November 2003 3:18 AM > > > > > To: Maven Developers List > > > > > Subject: Re: [VOTE] Make groupId mandatory for POM version 4? > > > > > > > > > > > > > > > Is POM v4 a 1.0, 1.1, or 2.x change? > > > > > -- > > > > > dIon Gillard, Multitask Consulting > > > > > Blog: http://blogs.codehaus.org/people/dion/ > > > > > > > > > > > > > > > > > > > > Jason van Zyl <[EMAIL PROTECTED]> wrote on 14/11/2003 08:05:30 > AM: > > > > > > > > > > > On Thu, 2003-11-13 at 15:57, Vincent Massol wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'd like to make <groupId> a mandatory element in POM > version 4. > > > > > > > What > > > > > do > > > > > > > you think? The reason is that I don't what the default can > be if > > > > > > > it's not specified and if we want to have plugins that > > > > > start using > > > > > > > the id/groupId/type elements, there must be a groupId > defined. > > > > > > > > > > > > > > Here's my +1 > > > > > > > > > > > > +1 > > > > > > > > > > > > > Thanks > > > > > > > -Vincent > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > - > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- > > > > > > jvz. > > > > > > > > > > > > Jason van Zyl > > > > > > [EMAIL PROTECTED] > > > > > > http://tambora.zenplex.org > > > > > > > > > > > > In short, man creates for himself a new religion of a rational > and > > > > > > technical order to justify his work and to be justified in it. > > > > > > > > > > > > -- Jacques Ellul, The Technological Society > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
