An option is to for POM converstion in the deploy plugin to reformat as 4.0.0 format, as the underlying model has not been changed. This would make 4.1.0-model-based projects metadatas available for pre-maven-2.0.9 users.
We could also consider removing unecessary infos from the deployed poms : who cares what plugins are used to buidl the project, or what version of chekstyle it uses ? More confusing is when POMs use profiles : what profile where active during artifaction deployment ? This can impact the transitive dependencies resolution ! We could deploy a "generated" POM that reflects the enabled profiles and the maven model used to build the artifact. just my 2 cents... Nico 2008/2/12, Gilles Scokart <[EMAIL PROTECTED]>: > > I like very much the attributes syntaxe (after all, it is what we are > already using in ivy ;-) ). > > Is your intention to use it in the sources pom only, or also in the > published pom. In the seconf case, how do you handle the problem of > forward > compatibility? I mean, what will happen to all user that have an older > client and that want to use the repository (being maven implementation, or > alternate client like ivy or buildr)? > > However, I don't like very much the dependencyGroup tag. I think it make > the published pom more difficult to read from a program. I would preffer > to > have the published pom as simple as possible. There is already the > properties, the parent poms, the DependencyMgt, etc. that force your pom > parser to be very statefull. I think it's enought. > > Moreover, I think DependencyGroup it might be a confusing. In the first > mail, I thought it was a logical grouping of your dependency, something > like > the ivy configuration into which you can group dependencies so that a > single > module can come with different group of dependencies in function of how > you > want to use it. > > I also see someone mentioning the need for excludes. You can maybe take > some ideas from ivy there (there is a transitivity="false" that you can > add). > > > Gilles > > > > 2008/2/11, Brett Porter <[EMAIL PROTECTED]>: > > > > Hi, > > > > I've always wanted to see an attribute based POM, so based on Nicolas' > > suggestion I killed some time after waking up early this morning to do > > it. > > > > JIRA: http://jira.codehaus.org/browse/MNG-3397 > > > > Here is a build to try: > > > http://people.apache.org/~brett/apache-maven-2.0.9-SNAPSHOT-terse-bin.tar.gz > > and svn branch: > > > http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-terse > > > > Here are two different files for comparison (it halved the size): > > > > > http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?content-type=text%2Fplain&view=co > > > > > http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplain&view=co > > > > What I did is basically convert all the primitive types in the model > > to attributes. I think more could be done (flattening lists, doing the > > same for plugin configuration elements), but this gets a big win at > > least in the dependencies section for minimal work. > > > > It should be completely backwards compatible. It detects v4.0.0 and > > reads it like it used to (then internally converts to the 4.1.0 Java > > model). > > > > Here's some notes on the implementation so far (again, go easy, I just > > whipped this up today and it's not production ready): > > - I see this as a stepping stone to the final solution. I've said this > > before, but I think the POM should separate the build information from > > the project metadata (particularly that stored in the repository). I > > think we need to take baby steps towards that though. > > - this could feasibly be applied to the settings and profile files too. > > - I switched to StAX in the process. This is likely going to introduce > > some small quirks we need to iron out (like the hack I added to parse > > Trygve's name - why did we ever allow that!) I think ideally we'd use > > the Xpp3Reader for 4.0.0 and the StaxReader for 4.1.0 for best > > compatibility. This would also fix the problem in that I've just > > removed the Xpp3Reader and so some plugins may choke. I'm sure the > > release plugin won't be happy, for example. > > - There is probably a slight performance overhead in reading v4 POMs > > since it repopulates the model twice. I haven't measured it but if > > it's an issue we could optimise the reader/converter. It also adds > > about 200k to the maven-model JAR. > > - It is very close to detecting based on namespace so we could enforce > > the use of that instead. > > > > Enjoy! > > > > Cheers, > > Brett > > > > -- > > Brett Porter > > [EMAIL PROTECTED] > > http://blogs.exist.com/bporter/ > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Gilles Scokart >
