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.
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.
Updated Apache Ant groupId.
Better exception handling in the Maven wrapper plugin Mojo.
Documentation updates, switched to org-mode instead of markdown.
Configurable base distribution URL for the Maven binaries location.
Missed a word in the README file.
Added the default base distribution URL to the README file.
Deleted unused maven folder in the root project directory. Updated th…
…e POM to fix random build failures by removing m2e eclipse settings.
Added plugin help and code comments for the help contents automatic g…
Minor pom modifications
Please ignore this pull request, will perform many more customizations and deploy the wrapper to sonatype under my current Maven groupId.
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'm interested in your use cases.
If there is any interest in this type of workflow I can work on the ASF contribution bits.
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.
Before getting to the use-cases, some quick answers to your questions:
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.
@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!