In a corporate environment, it would be nice to have a default settings.xml. It could be put at .mvn/wrapper/settings.xml and the mvnw script would install it if the user doesn't have a settings.xml. Thoughts?

In mvnw, the use of $(pwd) to invoke commands instead of `pwd` to do it is a bashism. This can be fixed either by using the sh-compatible backtick version or specifying /bin/bash in the shebang. Some GNU/Linux distributions ship with minimal sh-compatible shells as the default /bin/sh instead of bash. Debian switched to dash a while back, and I think Ubuntu followed that as well but I haven't checked.

Hi, now the layout of maven-wrapper is :

${basedir}/mvnw
${basedir}/mvnw.cmd
${basedir}/.mvn/wrapper/maven-wrapper.jar
${basedir}/.mvn/wrapper/maven-wrapper.properties
${basedir}/.mvn/wrapper/MavenWrapperDownloader.java

${user.home}/.m2/wrapper/dist/xxx/apache-maven-<ver>-bin/

The downloadable artifact maven-wrapper.jar is placed in the project dir. Can we cache this jar in user conf dir at ${user.home}/.m2/wrapper/maven-wrapper-<ver>.jar or ${user.home}/.m2/wrapper/launcher/maven-wrapper-<ver>.jar? Then there is no generated files of the building project in non-${basedir}/target dir.

Hi, I think the entry scripts mvnw{,.cmd} take much codes of the original mvn{,.cmd} and use own wrapper launcher to replace plexus launcher in order to do some provision actions. So the behavior of mvnw + wrapper_launcher should be almost the same as mvn + plexus_launcher.

From maven 3.5.0, M2_HOME is removed, and the property library.jansi.path is set, but our mvnw is not followed up. So we need to sync mvnw to the default maven dist (3.5.0+).

Here is two solutions:

• a) manually update codes of mvnw and wrapper launcher to mimic the boot progress of our selected maven version (3.5.2 now), and each time we update the default maven, we should do this again.
• b) do little refactor, wrapper only assemble the dist path and optionally downloads/install the maven dist, then exec into the original mvn

Personally I prefer b), the boot behavior is always sync to selected maven version by user and wrapper project is more simpler; the only cons may be that on some machine without md5sum command, we have to execute an additional java process to assemble the maven home.

Wouldn't be possible to download the jar with curl if the jar is not available?

This could be a patch on the script.

if [ ! -f $MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar ]; then
    curl -o $MAVEN_PROJECTBASEDIR/.mvn/wrapper/maven-wrapper.jar http://central.maven.org/maven2/io/takari/maven-wrapper/0.1.4/maven-wrapper-0.1.4.jar
fi

the same would have to be done on the .cmd

Someone just submitted a pr on Apache artemis using this wrapper, and the first question that came to mind was the wrapper.jar that would have to be commited as part of the source code.

I extended the scripts to allow usage of maven-wrapper without requiring the jar to be checked in with the rest of the sources. If the jar is found (because it is checked in or if it had been downloaded peviously) this is used, if not several options are tried out depending on the platform:

• Windows:

  • powershel is used to download

• Linux/Mac:

  • curl
  • wget
  • if both are not available a java class is compiled and executed to do the download.

I didn't add the java option to the windows script for now as far as I know the powershel option should be available on all windows systems.

I had a maven settings.xml already， 我已经有了一个settings的配置文件， it include my own nexus server，and other setting like plugin,profile, 包含了自建的nexus私有仓，以及像插件和profile， How can I use mvnw with this setting file for the default？ 我如何在mvnw中默认就使用这个配置文件？

Maven 3.4 snapshots are now being published with invalid zip files, where the entries are listed before their parent. So the logic in the Installer is faulty: you have to mkdirs() on all entries to be sure that the directory exists before you write the file.

We are hosting an nexus oss. Configuring the settings.xml for maven to get everything from there makes the wrapper installation fail. Initially i was thinking this is an issue on nexus oss side, but as you can see here https://issues.sonatype.org/browse/NEXUS-20863 it does not look like that. Mvnw tries to download the maven-wrapper-0.5.5.tar.gz without authentication, which is not allowed on our repository manager. How can we configure the settings.xml that mvnw uses the credentials from the settings.xml?

Ran into an issue where the wrapper pollutes stdout.

APPLICATION_VERSION=$(./mvnw -q -Dexec.executable="echo" -Dexec.args='${project.version}' --non-recursive exec:exec); echo "$APPLICATION_VERSION"

0.0.3-SNAPSHOT

rm -r ~/.m2/wrapper/dists/
APPLICATION_VERSION=$(./mvnw -q -Dexec.executable="echo" -Dexec.args='${project.version}' --non-recursive exec:exec); echo "$APPLICATION_VERSION"

Downloading https://repo1.maven.org/maven2/org/apache/maven/apache-maven/3.2.5/apache-maven-3.2.5-bin.zip
...................................................................................................................................................................................................................................................................................................................................................................................................................
0.0.3-SNAPSHOT

Please consider not writing this info to stdout, or write it to stderr.

using # in .cmd files as comment issues the following error: Der Befehl "#" ist entweder falsch geschrieben oder konnte nicht gefunden werden. aka command not found

MavenWrapperDownloader.java has issues with the generation of the path for the file maven-wrapper.properties. Due that the file is not readed, an alternative url in wrapperUrl is ignored.

For a proof of concept, please see https://git.sr.ht/~jumapico/maven-wrapper-reproduce-bug.

(I am aware that this project is frozen. However, this version of maven wrapper is still very common, including in new projects generated by Spring Initializr. Therefore, I request this be kept open as documentation for others on how to resolve this issue.)

The mvnw.cmd script that has a bug in the functionality that should loop over the .mvn/wrapper/maven-wrapper.properties, which causes the properties to not take effect. This is especially problematic in development environments that require the use of a maven repository other than Maven Central.

To fix the issue, in mvnw.cmd edit the FOR loop at lines 125-127 to add the usebackq option

FOR /F "tokens=1,2 delims== usebackq" %%A IN ("%MAVEN_PROJECTBASEDIR%\.mvn\wrapper\maven-wrapper.properties") DO (
    IF "%%A"=="wrapperUrl" SET DOWNLOAD_URL=%%B
)

Explanation: The double quotes around the filename causes the FOR command to treat it as string. But adding the usebackq option changes the FOR command to instead treat the double-quoted string as a filename set (reference)