Feature request: Make it possible to exclude wrapper scripts and downloader from the repository
hmontone opened this issue · comments
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:
- We would not have to store information other than strictly needed in project (
maven-wrapper.properties
) into repository - We could use Maven executable in usual way:
mvn ...
without extraw
-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.
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.