Mitigating verbosity of Maven pom.xml files (or: a critique of Maven by a fan)

Question

I like maven. I even like it very very much. Since I switched to it from Ant I have saved lots of hours of works, building build files, administrating dependencies, etc, and saved lots of space in my source control repository.

The problem is that maven files are too verbose. Not that Ant files where less verbose, but their verbosity was appropriate for what they do.

For example, instead of writing :

<dependencies>
<dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1.1</version>
<dependency>
    <groupId>com.myosproject</groupId>
    <artifactId>superlibrary</artifactId>
    <version>7.5</version>
</dependency> 
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>3.8.1</version>
    <scope>test</scope>
  </dependency>
</dependencies> 

I would like to write something like

<dependencies>
    commons-logging/commons-logging/1.1.1
    com.myosproject/superlibrary/7.5
    test:junit/junit/3.8.1
</dependencies>

Or instead of

<build>
    <plugins>
        <plugin>
             <artifactId>maven-compiler-plugin</artifactId>
                 <configuration>
                     <source>1.5</source>
                     <target>1.5</target>
                 </configuration>
        </plugin>
    </plugins>

I would like

<build version="1.5"/>

And (last example and we are done), instead of writing :

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>native2ascii-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>native2ascii</goal>
            </goals>
            <configuration>
            <encoding>UTF8</encoding>
                </configuration>
        </execution>
     </executions>
</plugin>

I would like not to have to write nothing. Ie, maven would detect the presence of the native2ascii folder and do the right thing by default.

I know I am mixing built-in functionality with plugins and other things, but please try to look from the point of view of a maven user, who is very happy with the tool, but thinks he could be happier.

So:

1. Is there a way I can configure maven to work like this? (And would it be wise to do so)

2. Is there perhaps another tool I am not aware of that does this?

Answer 1

Maven configuration is certainly verbose, Maven 3 aims to address this amongst other things (see these videos for some idea), and there is a plugin for Maven 2 that allows for configuration to be defined in YAML. There's also an experimental "terse" branch that supports attributes, reducing the size of the configuration somewhat.

For example:

groupId: org.twdata.maven
artifactId: maven-yamlpom-plugin
version: 1.0-SNAPSHOT
packaging: maven-plugin
name: YAML POM Plugin
dependencies:
  - { groupId: org.apache.maven, artifactId: maven-plugin-api, version: 2.0 }
  - { groupId: SnakeYAML, artifactId: SnakeYAML, version: 1.1 }
  - { groupId: commons-io, artifactId: commons-io, version: 1.4 }
  - { groupId: dom4j, artifactId: dom4j, version: 1.4 }
  - { groupId: junit, artifactId: junit, version: 3.8.1, scope: test }
  - { groupId: xmlunit, artifactId: xmlunit, version: 1.2, scope: test }
build:
  plugins:
    - artifactId: maven-compiler-plugin
      configuration:
    source: 1.5
    target: 1.5
repositories:
  - id: snakeyaml
    name: SnakeYAML repository
    url: http://snakeyamlrepo.appspot.com/repository

---

With Maven 2, you can mitigate the verbosity by defining common configuration in a parent project, in the examples you cite, the dependencies can all be defined in the parent, or in the dependencyManagement section of a parent so a child can declare the junit dependency as

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
</dependency>

which is a bit of an improvement.

The plugins can both be declared in the parent and need not be defined in your child.

Answer 2

I completely agree with you that some parts of the pom.xml may be condensed, in particular the <dependencies> part.

I really like the Ivy way of declaring dependencies :

<dependencies>
    <dependency org="commons-lang" name="commons-lang" rev="2.0"/>
    ...

I've seen a blog post that proposed an experimental tool to create the dependencies as Ivy do. However, I've never tried it.