Mittwoch, 20. Februar 2013

Maven - From POM to HOM...

...and other ideas for a future maven releases

Bored by all the Ant-vs.-Maven-vs.-Gradle articles (sorry for all build tools not mentioned here), I'd like to give some ideas how Maven could be improved.

Sometimes, I swear about Maven when I don't get to where I actually wanted to go to. Or, I don't like the idea to run mvn clean install and it's deploying something to a database which means it's not at all doing for what Maven is actually designed for. But as I know what Maven can and what it can't and knowing that no build tool is perfect I don't want to change it.

So, here is a list of ideas which can be summarized as follows: ideas in paragraph 1 and 2 optimize the current implementation, paragraph 3 are ideas extending Maven for supporting continuous delivery.
Before I really start:
  • I assume that projects follow the existing maven conventions, e.g. having a hiearchical folder structure.
  • There exist no proof of concept if any of this ideas can be implemented.

1 - More convention over configuration...

... which would reduce the lines of configuration


no explicit parent declaration

the parent is one directory above, why do I have to declare that on five lines?

no artifactId declaration

Convention for the artifactId could be the folder name, recursivly concatenated with the parent folders (e.g. parent-child, parentA-parentB-child).

no version declaration for internal dependencies

dependencies which are modules of the reactor are internal dependencies, and normally have the same version. In other words: the ${project.verison} should be declared once in the root pom of the project.

reduce the amount of pom.xml

not all modules must have a pom.xml, especially intermediate folders being itself parent of submodules dont' always need a pom.xml. The file should be optional, taking groupId and version from the parent, artifactId is based on the foldername.

2 - Make the POM more human readable...

...the current one is ok for machines


Why not have attributes in the POM? Instead of configuring

the dependency could be configured with attributes*
    <dependency groupId="commons-logging" artifactId="commons-logging" 
                version="1.1.1" optional="true" />

*in a normal editor this would be a one liner

I would leave the current (stable) POM, but humans should configure the modules in a hom.xml, human (friendly) object model, which is tranformed to a POM at runtime. This could be easily done in a generic manner whith XSLT: all attributes are transformed to child elements.

3 - New features...

...we're not just building software, it also gets deployed!



It should be possible to override the version when a build is started
(e.g. mvn deploy -Dversion.override=1.2.3)
This would help creating "releases" in a lightweight manner without having any snapshots and is helpful when doing continuous delivery where a unique version is generated outside of maven and is reused for later deployments to different stages.

more lifecycles

apart from the existing build lifecycle which creates jars, ears and so on there should be more follow-up lifecycles
  • dist lifecycle, for creating a distribution
  • stage lifecycle, for deployment (not 'mvn deploy') to an environment (app server, database etc)
mvn clean install dist stage would (locally) build all modules, create a dist and deploy the dist to a (local) app server

Of course, the dist lifecycle can be integrated in the existing build lifecycle (normally with the assembly plugin) but it should already be better integrated at all. Like with the ear type: Normally, the convention is enough, no or only little additional configuration is necessary. Compared to the assembly descriptor files. Why not have a packaging type like zip/tar (and rpm, deb, exe etc.)?

That's it...

...for now

Next thing for me would be to play around with the one (hom.xml) or other idea (mvn stage) to see what is feasible.