...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
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
<optional>true</optional>
</dependency>
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!
version.override
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)
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.)?
