"Vincent Massol" <[EMAIL PROTECTED]> wrote on 20/11/2003 07:38:18 PM:
> 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: Yep, we are CHANGING the POM here guys during a RC to release cycle. Is this really the place to do it? I wouldn't have thought for stability reasons we'd do it. > 1/ modified marshaller/unmarshaller to support top level <type> element. > That doesn't change any existing code Yep. > 2/ modified marshaller/unmarshaller to support top level <version> > element (in addition to <currentVersion>, not touched) What is the difference between <version> and <currentVersion>? I can't find any docs on it in the user's guide. it is really similar to the <versions> top level tag in name too. > 3/ modified marshaller/unmarshaller to support top level <artifactId> > element (in addition to <id>, not touched) Yep. > 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). Doesn't really affect the POM as such, and IMHO this was a good idea. > 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 Yep. > That's all I did and I don't believe it can cause any trouble. What I Ok, here's my problem. Now that we have: <type>, <version> and <artifactId> marshalled people can start using them in their scripts, java code and other places and will rely on it being there. Are these features ONLY supported if pomVersion is 4? it doesn't look that way, and if not, then we have an issue. People will always find these undocumented loop holes to get them past something, and then we need to support it. I don't have a problem with most of the changes, for me it's a timing and implementation issue. I'd rather maven 1.0 supported pom version 3 ONLY. And enforced the v4 stuff some other way if it has to happen now. > 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). I'm -1 on the <compatibilities> element. Why: - My first reaction is that it's badly named. I understand what project dependencies are pretty easily. Compatibilities look like a runtime dependency to me. Is this close? I couldn't find any more documentation on it at the wiki or anywhere else. - I haven't seen enough detail on what goes into a compatibility element - Why are compatibilities only for maven's runtime. Why not JDK versions, JRE versions, operating systems etc. - I don't have enough information to agree that it's a 'good thing' at the moment. Feed me some more detail. > 9/ modify the multichanges plugin to add href links to the generated > report (for POM4 only as it requires info from <type>). Why not reuse the maven.multiproject.type property since it's already there and does the very same thing without changing the pom? This works already for existing multiproject sites and we have far too much duplication of the multiproject concept as properties now. > 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/)? I think we need to talk about my comments above on letting users access v4 features in a v3 POM. I think we should talk about timing. I don't think introducing a new POM version in a RC to release cycle is wise. I also think I need more info on what the proposal is for the compatibility element. The details at http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=11486 just aren't enough for me. I understand you guys may have talked more about this on IRC. Sorry I missed the discussion, but I hope this is useful feedback. If not, just tell me and I'll step out of the way. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
