atom feed58 messages in org.apache.maven.devAn Attribute Based POM
FromSent OnAttachments
Brett PorterFeb 10, 2008 10:44 pm 
Tim O'BrienFeb 10, 2008 10:58 pm 
Jason van ZylFeb 10, 2008 11:11 pm 
Brett PorterFeb 10, 2008 11:12 pm 
Niall PembertonFeb 11, 2008 3:40 am 
Stephen ConnollyFeb 11, 2008 4:05 am 
Brett PorterFeb 11, 2008 4:23 am 
Tomasz PikFeb 11, 2008 4:39 am 
Brian E. FoxFeb 11, 2008 7:25 am 
Paul BenedictFeb 11, 2008 8:08 am 
Jason van ZylFeb 11, 2008 8:33 am 
Brett PorterFeb 11, 2008 1:50 pm 
Michael McCallumFeb 11, 2008 3:53 pm 
Martijn DashorstFeb 11, 2008 4:16 pm 
Ralph GoersFeb 11, 2008 7:21 pm 
Brett PorterFeb 11, 2008 8:05 pm 
Michael McCallumFeb 11, 2008 8:13 pm 
Shane IsbellFeb 11, 2008 8:48 pm 
Jason van ZylFeb 11, 2008 9:21 pm 
Don BrownFeb 11, 2008 9:22 pm 
Jason DillonFeb 11, 2008 9:33 pm 
Brett PorterFeb 11, 2008 9:35 pm 
Don BrownFeb 11, 2008 9:46 pm 
Brett PorterFeb 11, 2008 9:50 pm 
Don BrownFeb 11, 2008 10:01 pm 
Jason DillonFeb 11, 2008 10:03 pm 
32 later messages
Subject:An Attribute Based POM
From:Brett Porter (
Date:Feb 10, 2008 10:44:49 pm


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.


Here is a build to try: and svn branch:

Here are two different files for comparison (it halved the size):

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.


Cheers, Brett