Maven wrapper project - from Jar library to Maven plugin

Last month, the maven-wrapper project caught my attention on Github.

This morning, I had time to kill and I decided to take a closer look at it. I eventually played with it, forked it and added a quick and dirty feature "basic Maven plugin support".

The maven-wrapper project is a port of the Gradle wrapper to Maven.
It will download a Maven distribution automatically for you and set it up. Currently the project is just a library, more or less a work in progress at this time.

Again, I can't emphasize enough on the importance of build tools wrappers, especially on build machines. The release management folks doesn't need to follow any detailed setup guide, nor do they need to worry about managing multiple versions of the same build tools.

"Plugin-ifying" the maven-wrapper project
I did a very quick and dirty implementation of a Maven plugin, so that the code could be reused as a plugin in new or existing Maven project.

It was just a matter of adding few dependencies and writing a simple Mojo.
I eventually renamed the artifactId to have auto-mapping enabled in terms of namespace and goals.

Nowadays, it's possible to write Mojo descriptors with Java annotations instead of xdoclet-like comments.

I opened a pull request to merge the code in the original project few hours ago.

Maven wrapper plugin usage
Checkout the maven-wrapper forked project and run the Maven install goal.
mvn install

In another Maven project, add the following to your build->plugins section

    <build>
 ..
 
         <plugins>
   ..
      <plugin>
        <groupId>org.apache.maven</groupId>
        <artifactId>wrapper-maven-plugin</artifactId>
        <version>0.0.1-SNAPSHOT</version>
      </plugin>
   ..
    </plugins>
 ...
    </build>
    

Maven version compatibility
In terms of compilation, it should work with Maven 3.0.2 dependencies and above. The default distribution URL contains some maven versions from 2.0.9 to 3.0.5.
The distribution URL is not customizable automatically at this point (when generating the wrapper supporting files).


What would be nice to have in terms of configuration

• POM driven customization of the default settings (launcher names and location, distribution URL). It's currently possible to do it manually though.
• Token substitution inside the plugin when generating wrapper artifacts.

Build Tools Wrappers

Today I stumbled upon a new project called maven-wrapper.
I haven't tested it myself, but it looks like a very promising effort. Users/Developers will be able to perform builds without an existing Maven installation.

Grails and Gradle already have a way to generate wrappers.
Antw seems similar to gvm in terms of concepts and approach.

Those tools wrappers allow users to build programs without having the software already installed on their local machines.

This is particularly interesting for build servers, and more specifically continuous integration servers:

• Many projects may require different versions of a build tool.
• Sometimes the setup of the build tools on a server involves following many processes and getting couple of approvals.
• There's a risk of human error that will result into a corrupted non-working software installation (i.e. moving few files around to follow corporate conventions -> broken scripts, file permission issues, etc.).

There are often issues related to build tools in terms of software distribution and usage:

• People got a copy of the source code, but they don't know how to build it.
• The user knows the build tool to use, but he doesn't know how to set it up (Environment variables, PATH manipulation, etc.)
• The user knows how to setup the build tool and build the application, but not how to configure the project inside an IDE
• etc.

I expect more and more build tools (as well as full-stack frameworks) to provide the ability to generate seamless wrappers, as it is a very convenient feature.

Gradle over Maven for Groovy/Java projects

* "The Ant" problems

For many years, I've been down with Maven and I still am. In many projects, I've seen some gigantic Ant scripts. Ant has often been a maintenance nightmare in huge applications, fix a script and notice that your eyes are bleeding.

As "most"corporate developers don't use Ivy to resolve dependencies with Ant, you typically end up with 3 scenarios:

• The dependencies are stored in the version control server, that can get people fired at few places.
• There's some kind of repository concept with jars at dedicated locations (Windows shares, NFS, etc.). The dependency resolution involves tons of scripting or some Ant tasks.
• Dependencies are stored at a secret location(mapped drive to a Windows share that you'll know about one day) and you can only build after lots of configurations.

Some of the good things about Ant are flexibility, accessibility, documentation. Most developers know how to use Ant and writing custom tasks is not usually hard.

* Maven 

My initial Master thesis subject was supposed to be about Apache Maven, but I bailed out... If I recall correctly Maven had only beta releases at that time with very little documentation.

After downloading Maven binaries, I didn't know what to do and how to use it: close to zero documentation and not really "accessible". When I was about to finish my MBA, I decided to give it another shot. It felt like "I looked at Maven and I got scared...".

The Jelly Issue

While many people didn't like Jelly, it provided some basic scripting capabilities inside the build file. If I recall correctly plugins also needed some Jelly files and many developers were annoyed by that constraint.


Sometime ago, I wrote an automation tool with Commons Jelly to setup Web hosting on Tomcat.
The tool was a launcher with few relatively small Jelly scripts to perform the following:

• Read the list of users from an excel spreadsheet or XML file 
• Setup FTP accounts 
• Modify the Tomcat XML files to create application context paths for Web applications 
• Populate the user information in a database(credentials, ftp and tomcat information)
• Send email notifications with the account details.

Understanding Jelly made my life easier with Maven until it reached 2.x and Jelly was dropped at that time, if I recall correctly.

Maven evolution

With Maven 2.x things got cleaner and more stable, documentation got better and so on. Still many companies didn't give Maven a second chance. Then came Maven 3 and things haven't changed that much at the corporate level.

Most Java development companies still use Ant and few of them use Ivy to resolve dependencies. I do see Maven here and there, time to time, but not that often.

Maven adoption

From my experience, Maven has always been an issue in non Open-Source projects: too complicated, not worth the effort, too much impact on the typical IDE or build/release workflows.

While convention over configuration introduces a potential "lack of control" or flexibility, it also have its pros.

* Gradle to the rescue

In the past, I've not really been a big fan of any kind of dynamic or scripting language, unless it's used for scripting or as an extension module. I would probably never have considered Gradle and similar tools in the past, because it would have made me feel "uncomfortable".

Nowadays, I'm willing to take advantage of Groovy, Jython, Clojure or whatever.

If I were doing some Clojure, I would try cake or lein as build tool, unless there's a feature that I need that is only available in Maven. Why? For just 3 main reasons :
- A tool dedicated to a programming language, often means more power and integration.
- There are not many attempts to do too many things or to be too generic, things are easier.
- Having scriptable builds and zero XML is cool.

Accessible to Java Developers

While a Groovy DSL to write a build script is no XML or Java, it's more expressive.
Learning some basic Groovy concepts is easy for Java developers.

Solid documentation

I was impressed when I saw the Gradle manual. It's very good and it's easy to read and understand.

Readable files

Last year, after migrating few personal projects from Maven to Gradle, I felt relieved. I didn't have some crazy POM files, but still too much XML to write (or copy/paste).
The Gradle build files were easier to read/understand with less lines of code.

Flexibility

Adding custom tasks with Groovy Code, without writing plugins unless you need too, this is really nice. If you need plugins there are couple of them out there.

While there are not as many plugins for Gradle as for Maven, I believe that Gradle is getting more  momentum. Many projects such as Hibernate already switched from Maven to Gradle.