Maven plugin support for reuse in existing or new Maven Projects. #1

wants to merge 11 commits into


None yet

2 participants


Wrapper the maven-wrapper into a Maven plugin and updated the README file.
It would be nice to support more configuration in the future, hard-coded some settings.

Rimero Solutions Wrapped the existing maven wrapper project into a maven plugin and up…
…dated the README file.

It would be nice to support configuration in the future. Harcoded the some settings for now.

The default artifact id was changed to automap the 'wrapper' prefix in the Maven goal.

Rimero Solut... added some commits Jun 20, 2013
Rimero Solutions Updating documentation 6c1de73
rimerosolutions Fixing typo 0117af0
rimerosolutions Updating documentation 9e068b5
Rimero Solutions Updated Apache Ant groupId.
Better exception handling in the Maven wrapper plugin Mojo.
Rimero Solutions Documentation updates, switched to org-mode instead of markdown.
Configurable base distribution URL for the Maven binaries location.
Rimero Solutions Missed a word in the README file. d75ada1
Rimero Solutions Added the default base distribution URL to the README file. d30def5
Rimero Solutions Deleted unused maven folder in the root project directory. Updated th…
…e POM to fix random build failures by removing m2e eclipse settings.
Rimero Solutions Added plugin help and code comments for the help contents automatic g…
Rimero Solutions Minor pom modifications 6dd06c8

Please ignore this pull request, will perform many more customizations and deploy the wrapper to sonatype under my current Maven groupId.

bdemers commented Jul 8, 2013

Lots of good stuff this pull request!

A couple important notes though, the original point of the Gradle wrapper is to check in a tiny jar file into each project. This would then download and bootstrap a gradle instance. So all a developer needs to do is check out/clone a project and build it.

Couple things to think about.

  • I don't own the IP to the original wrapper (and have not contacted Gradleware, about a code donation to the ASF)
    ** The license is Apache 2.0 so it can be consumed or reused under a non org.apache groupId
  • The added dependencies in this pull request will bloat the tiny jar, and nobody wants to check in a larger jar into source control
  • I've been toying with the idea of doing everything in script (bash shouldn't be a problem, but on windows? maybe powershell has a curl/wget equivalent ?)
    ** script could then download some minimal jar and/or configuration and/or maven bundle needed to bootstrap maven (then maven can download the rest of the world)

I'm interested in your use cases.
If there is any interest in this type of workflow I can work on the ASF contribution bits.


Hello Brian,

Thanks for getting back to me.

In general, my additions allow generating dynamically the wrapper as part of the build process, the same way that the Gradle Wrapper does (run a goal that generates a wrapper). I have updated the maven-wrapper fork documentation.

I also created a very small maven-wrapper-example project that you may want to check out for further details.

Some answers

Before getting to the use-cases, some quick answers to your questions:

  • The wrapper remains light, as the dependencies are build-time only (Maven mojo/plugin). The tiny wrapper jar remains tiny, with no extra jars around. Additional dependencies will not be part of the command wrapper artifacts or runtime dependencies.
  • You're right in terms of licensing, I will see if I can't get in touch with Gradleware in that regard. I've setup the license as Apache 2.0, there's a reference to your project in my fork and you're also in the list of developers in the POM, I only implemented the Maven Mojo part.
  • I think that the bash idea is not really portable, there's already a fork of your project with that kind of idea in mind. The Maven plugin that I implemented removes the need of bash scripting completely, again try to check out the maven-wrapper-example project.
  • I already uploaded a snapshot version of the Maven wrapper plugin to the Sonatype OSS repository to make the distribution easier. I think that they rsync to Maven central, but yes it would be better if the plugin was under Apache and a built-in Maven plugin.


  • I have a new or existing Maven project
  • I understand the concept of Gradle Command Line Wrapper and want to take the advantage of the Maven Wrapper.
  • I add the plugin to the build section of my Maven POM and a reference to the Sonatype OSS repository in my pluginRepositories section.
  • I notice that the Maven Wrapper plugin detects my current Maven version and uses it to generate the wrapper properties file for the download URL.
  • I can also customize the wrapper output folder with a path relative to my project folder.
  • I realize that the Maven Wrapper really IS the same as the Gradle Wrapper except that it's not a built-in but provided plugin. One distinction is that there's no option to specify a fixed version of Maven, always auto-detected, but that can be fixed easily with a condition and a variable...

Maven Wrapper changes

  • The modified Maven wrapper is a configurable Maven plugin:
  • wrapperDirectory: Instead of hardcoded maven/wrapper folder (some of the code might have been hardcoded here if I recall correctly)
  • baseDistributionUrl: Fetch the wrapper from custom locations (still customizable in the wrapper properties file manually)

Further possibilities

I think that many build tools can benefit from the 'general' layer that auto-downloads the requested zip and setup permissions. The only difference for an 'AnyJavaToolWrapper' is about how the launching process is bootstrapped (JVM options, system properties, eventually additional classpath/classloader for complex tools).

Let me know what you think!


I just double-checked the Gradle license, it is Apache, so there is no harm.

bdemers commented Jul 9, 2013

@rimerosolutions Have you ever signed an Apache CLA? If not check it out. We can scrub the headers later if we move forward with this.
As you noticed the license is fine, we can do what we want with it, however it cannot be included in the Maven project (or anywhere in the ASF) unless either gradleware and the copy write holders sign off on it (but i'm not lawyer).

I have defiantly thought about making this more generic. Or at least a generic core, that could be used by anything (possibly consumed by gradle and maven)

Another thought I had was to use a webstart app to install a maven bundle.

Thanks for the clarification on the pull request! Sounds like we are on the same page, and that I should have just taken a longer look at the code!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment