Feature request: Make it possible to exclude wrapper scripts and downloader from the repository

[hmontone]

If I am not mistaken, files other than .mvn/wrapper/maven-wrapper.properties should not really be in project/repository itself, at least ideally. How about if there was a way to install Maven wrapper in a way that mvnw/mvnw.cmd -scripts would be installed into some directory in PATH, and MavenWrapperDownloader.java would be located in some global location (e.g. $HOME/.m2/wrapper/MavenWrapperDownloader.java). Wrapper-scripts could use .mvn/wrapper/MavenWrapperDownloader.java if it exists, and fall back to global MavenWrapperDownloader.java otherwise. This would have some advantages:

1. We would not have to store information other than strictly needed in project (maven-wrapper.properties) into repository
2. We could use Maven executable in usual way: mvn ... without extra w-letter or path to current directory. This would be more intuitive way of using Maven for most of us, I think.

Currently it is possible to copy mvnw -script as mvn into some directory in PATH, and it works just fine. However, MavenWrapperDownloader.java is searched from .mvn/wrapper -directory under project directory. Straightforward way of fixing this would be to set fallback location of MavenWrapperDownloader.java to wrapper/MavenWrapperDownloader.java under the base directory of settings.xml -file.

[gzm55]

MavenWrapperDownloader.java could be inlined into scripts and generated as a tmp file.

For entrance scripts, it follow the designs of gradle wrapper.

The pros of putting the bootstrap scripts into project:

• project can be build iff jdk is ready after project source is git-cloned, the building should be as portable as possible.
• project can fixed the version of bootscrap scripts it used, or even use a custom version of wrapper. The wrapper script contains some logic not compatible to every versions of maven.

The wrappers define a project level executable interface convention for triggering the build process. If a project can depend more environments elements other than jdk/os, it could be better to call system mvn directly, and check the required maven version in pom.