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
