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:

The issue is being tracked under MNG-3397.

The result is that something like this:


Halves in length to something like this:

  <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!)

18 responses to “Experimental Maven support for condensed POMs using attributes

  1. well, 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.

  2. it’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.

  3. Brett, 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!

  4. Well done Brett. We’ve been waiting for this one. How long until it makes its way into a final release?

  5. Guillaume Bilodeau

    Absolutely wonderful, thanks a *bunch* for this! POMs will be much easier to read with this feature.

  6. I 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.

  7. Emmanuel Venisse

    Brett, dependency declaration can be simplified more. For example, we’d can use that:

  8. Awesome! 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!!!

  9. I 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.

  10. I hope this makes the next release.

    The willCode4Beer guy, namely me, will buy you a round.

  11. Very cool – nice work, Brett!

  12. Brian – point taken is well taken. I’ve changed the title. I hope the rest of the entry was clear enough about this.

  13. I like it! I welcome more compact POM’s!

  14. Excellent news, looking forward to more condensation.

  15. This 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

  16. I 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.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s