Experimental Maven support for condensed POMs using attributes
As I’ve just posted to the Maven developers list, 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’s what you’ll need to try it:
- a build: http://people.apache.org/~brett/apache-maven-2.0.9-SNAPSHOT-terse-bin.tar.gz
- or if you prefer to roll your own, the source: http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-terse
The issue is being tracked under MNG-3397.
The result is that something like this:
...
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>easymock</groupId>
<artifactId>easymock</artifactId>
<version>1.2_Java1.3</version>
<scope>test</scope>
</dependency>
...
Halves in length to something like this:
...
<dependencies>
<dependency groupId="junit" artifactId="junit" version="3.8.1" scope="test"/>
<dependency groupId="easymock" artifactId="easymock" version="1.2_Java1.3" scope="test"/>
...
What I did is basically convert all the primitive types in the model to attributes. I think more could be done - for instance, lists could be flattened if the parent element is not really needed for grouping, and I think plugin configuration should get the same treatment as above - but this gets a big win for minimal work. Also, the settings and profiles files could conceivably get the same treatment.
Most importantly - the work is completely backwards compatible. Maven detects v4.0.0 POMs and reads it like it used to. Even, as in the case of Archiva above, if there are different ones within a project.
Now, it’s early days for this change, and there are a few issues to note:
- I switched from our bundled XPP3 based parser to StAX. This will likely introduce some quirks that will need to be ironed out through testing. I will likely in the future read the old models with the old parser, and the new ones with the new parser.
- Some plugins may not work with this version (I’m guessing at this stage the release plugin falls into this category though I haven’t checked) - as I removed the old parser altogether. This should be easy to make compatible.
- I haven’t tested performance with this new version - I expect that the v4.0.0 POMs will parse marginally slower than they used to and this may affect artifact resolution times. It also increased the size of the Maven download.
What comes next? Apart from correcting issues such as the above, I have in mind:
- A simple plugin to convert from v4.0.0 to v4.1.0 for a POM file so you can try this out on your own projects.
- Utilising the namespace for detecting the version so the modelVersion element is not required.
- Further improvements to the format
What do Maven users think of this alternative format?
(And apologies to Don, I got carried away doing this instead of finishing the integration of his patches into the main branch - but I’ll resume that again shortly!)
- BROWSE / IN TIMELINE
- « Blog Moved to Exist, and Wordpress
- » Cloned Mac migration problems? Check your permissions
- BROWSE / IN Java Maven
- « Searching Archiva with Quicksilver
- » Working around –non-interactive problems in Leopard’s Subversion
COMMENTS / 18 COMMENTS
Steve Loughran added these pithy words on Feb 11 08 at 5:06 amwell, you’ve probably just broken anything using XSL transforms to manipulate the content, or third party tools that work with it. Like the repository search tools, Ivy, etc.
bporter added these pithy words on Feb 11 08 at 5:21 amit’s going to take some time to see this adopted if it is (it hasn’t even hit a current version yet). I also expect that this won’t be adopted in the repository - we’ll deploy the original format - at least until we have a real extensible format in there.
Don Brown added these pithy words on Feb 11 08 at 5:24 amBrett, you rock! I’m so excited to see fundamental changes like these going into Maven. At times, I’ve worried that Maven was being shaped by the needs of big consulting clients at the expense of the average Maven user, but something like this proves me wrong. Even for the simple case of a user wanting to see what dependencies a project has, this compact syntax will save heaps of digging around the XML soup. Good work!
Daren Bell added these pithy words on Feb 11 08 at 10:31 amWell done Brett. We’ve been waiting for this one. How long until it makes its way into a final release?
Guillaume Bilodeau added these pithy words on Feb 11 08 at 7:20 pmAbsolutely wonderful, thanks a *bunch* for this! POMs will be much easier to read with this feature.
Matt Raible added these pithy words on Feb 12 08 at 12:02 amI dig it - A LOT! With any luck, we’ll get attributes for other elements and reduce many, many poms from hundreds of lines to tens.
Emmanuel Venisse added these pithy words on Feb 12 08 at 3:18 amBrett, dependency declaration can be simplified more. For example, we’d can use that:
Taylor Gautier added these pithy words on Feb 12 08 at 11:59 amAwesome! I’m tired of seeing people whine about how Maven sucks at this and that but they don’t actually contribute anything. You actually did something about it. Bravo. Looking forward to cutting our poms down!!!
Brian Fox added these pithy words on Feb 12 08 at 12:15 pmI think it does Maven a disservice to broadcast a statement like the title of this blog when it isn’t in the trunk and isn’t even fully defined yet. (ref the active dev thread on the subject) Less hype please.
Paul Davis added these pithy words on Feb 12 08 at 1:01 pmI hope this makes the next release.
The willCode4Beer guy, namely me, will buy you a round.
bporter added these pithy words on Feb 12 08 at 6:05 pmBrian - point taken is well taken. I’ve changed the title. I hope the rest of the entry was clear enough about this.
Trond added these pithy words on Feb 13 08 at 4:49 pmI like it! I welcome more compact POM’s!
Árni Hermann Reynisson added these pithy words on Feb 13 08 at 6:03 pmExcellent news, looking forward to more condensation.
Tony Nys added these pithy words on Feb 14 08 at 7:12 amThis will become really handy,
now poms get really big and hard to maintain.
Everything reducing the poms will help.
To not break XSLT transformations, someone can create an XSLT transforming the “new” pom to an original one
Neil Crow added these pithy words on Feb 27 08 at 8:13 amI like it!
I’d also like to see some externalised configuration, I dont believe that it all belongs in the pom.
Especially stuff like the cargo configurations for testing against different profiles (unit, intg etc.)
SPEAK / ADD YOUR COMMENT
Comments are moderated.


Recent Comments