takari / maven-wrapper Goto Github PK

View Code? Open in Web Editor NEW

This project forked from bdemers/maven-wrapper

1.6K 1.6K 234.0 481 KB

The easiest way to integrate Maven into your project!

License: Apache License 2.0

Java 100.00%

maven-wrapper's People

Contributors

Stargazers

Watchers

Forkers

agudian vogellacompany dsyer wrmsr bhamail valery-barysok loganfreeman gengar003 ksperling izeye cyrille-leclerc therevoman epiclabs-io yongjhih ttddyy rzs840707 pombredanne dweomer ail-man michaldo geekcheng datalogics digideskio mincha feroozkhanchintu skaverhagen jchavez dshamanthreddy vsaliy douglasmelo vicaya rockyspade mattlk13 ramazangirgin stephensorriaux lovejavaee levsa sanjiang-opensource adangel robertnorthard danielnorberg elexx kutzi hazendaz nunalves chrisdutz cornorr emawind84 bou2you maxim-zolotov alainlompo sportsbitenews hcgpragt eprst slachiewicz rawbertp lreimer mysonhushu panho66 dappes mauriziocasciano shiny777 cnopens eninja jamesyangwang mochushile ktenman hopisaurus vdotjansen shresthaujjwal shanmine wmunevarmovilidad justin-foote julianhyde bokovhu joekerouac ymarutiprasad singarajum alexproca ivan97 buckett jlmuir thro-infm18 adrianshum zhoushineyoung olx-global nliebelt chtompki citux nguyenphuongktqt rfscholte cathong injeti-manohar rmcmahon akeeton jarst vilish t-sagar sudhanshukedia guylabs

maven-wrapper's Issues

Typo in comment in mvnw.cmd causes script to fail

In mvnw.cmd, there is a comment that starts with # instead of @REM which causes the script to fail on Windows Server 2002 (and probably other versions).

Maven wrapper fails when there are spaces in arguments.

This works:

mvn com.smartcodeltd:release-candidate-maven-plugin:version "-DoutputTemplate=##teamcity[setParameter name='env.PROJECT_VERSION' value='{{ version }}']"

This does not:

./mvnw com.smartcodeltd:release-candidate-maven-plugin:version "-DoutputTemplate=##teamcity[setParameter name='env.PROJECT_VERSION' value='{{ version }}']"

The error is

[ERROR] Unknown lifecycle phase "name='env.PROJECT_VERSION'". You must specify a valid lifecycle phase or a goal in the format : or :[:]:. Available lifecycle phases are: validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy, pre-clean, clean, post-clean, pre-site, site, post-site, site-deploy. -> [Help 1]

Both the installed and wrapper versions of Maven are 3.3.9

Maven wrapper dosen't allow to override local configuration from .mvn/maven.config

Standalone maven allow to override configuration from maven.config, but maven wrapper does not.

This issue is described in ~~https://issues.apache.org/jira/browse/MNG-5930~~ https://issues.apache.org/jira/browse/MNG-6235

Unignore files from gitignore

Often in a project the top level gitignore will include *.jar which will exclude all jar files. But the maven-wrapper.jar needs to be un-ignored.

gitignore files are specific to the directory they are in and the subdirectories. So you could generate a .mvn/wrapper/.gitignore file which would explicitly un-ignore these files. The contents of this file would look like:

!maven-wrapper.jar
!maven-wrapper.properties

Failed to execute goal org.apache.rat:apache-rat-plugin:0.12:check

Hi there,

I want to use your wrapper but after running the "mvn -N io.takari:maven:wrapper" instruction i'm i've starded to get the error below. Why is the wrapper activating apache rat?

[ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.12:check (default) on project we.retail: Too many files with unapproved license: 1 See RAT report in: /Users/pimparic/projects/aem-sample-we-retail/target/rat.txt -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.rat:apache-rat-plugin:0.12:check (default) on project we.retail: Too many files with unapproved license: 1 See RAT report in: /Users/pimparic/projects/aem-sample-we-retail/target/rat.txt

Regards,
Ricardo

Quoted arguments aren't properly passed through ./mvnw to maven.

Please see PR #13 for a description of the problem, the solution, and a code patch.

I apologize if I'm duplicating messaging here: I'm not sure what the proper process for takari/maven-wrapper is.

mvnw doesn't escape directory in find_maven_basedir and MAVEN_PROJECTBASEDIR

Hi.

I've noticed that maven wrapper doesn't use double quotes in find_maven_basedir/$MAVEN_PROJECTBASEDIR, so if current directory contains spaces, it will result in malformed computation.

I'm not sure how this project is managed (is mvnw somehow generated), so i didn't fork and send pull request

Promote Maven Wrapper feature request in README.md

Assuming that feature requests for Maven are mainly prioritized by votes, I guess one of the reasons why the Maven Wrapper is not "official" yet is because there are only a couple of votes in the corresponding Maven Wrapper feature request.

Wouldn't it be nice to promote the feature request by adding a direct link in the README.md?

Running from WSL Bash results in Error: JAVA_HOME is not defined correctly

When running wrapper script under WSL $ ./mvnw antrun:run@ktlint-format getting the following error:

Error: JAVA_HOME is not defined correctly.
  We cannot execute :/opt/java/current-java/bin/java

opt/java/current-java is a symlink to /opt/java/jdk/ installation folder. I suppose the script does not handle symlinks properly?

Launch From Finder Does Not Work

If I try to run mvnw from Finder (Ctrl-Click; Open) it throws this error:

/Volumes/Home/j.ward/Desktop/hello-springboot/mvnw ; exit;
~ $ /Volumes/Home/j.ward/Desktop/hello-springboot/mvnw ; exit;
Error: Could not find or load main class org.apache.maven.wrapper.MavenWrapperMain
logout

This is probably because there is some special sauce need to change the cwd to the directory Finder is in, instead of the default (user home dir).

Apparent inconsistencies regarding command line options

The Un*X script has this:

MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $@"
export MAVEN_CMD_LINE_ARGS
...
exec "$JAVACMD"  ... "$@"

I.e. MAVEN_CONFIG are added to the env var but not used in the actual command line.

The windows one has this:

set MAVEN_CMD_LINE_ARGS=%*

...
%MAVEN_JAVA_EXE% ... %MAVEN_CMD_LINE_ARGS%

I.e. MAVEN_CONFIG is ignored, but the env var is used on the command line.

I'm happy to fix it and send a PR if you can provide some guidance on what the actual intent was.

Also, what I ultimately want, which could be more of a discussion, I don't know, is to be able to change the maven command line arguments from a file that I can put in source control. I see that might be dangerous if the user wants to override it, but this is my current best hope to get a build that works for everyone out of the box, and yet doesn't have repositories (and distribution management) hard-coded in poms.

Remove TODO from `mvnw` script

It's common to search for comments with TODO in projects. This is done using grep, ack, rg or the TODO search feature of an IDE.

Unfortunately the mvnw script contains a TODO comment which is found in every project I work in. It would be nice if this comment could be removed or resolved.

OSX 8 still has JDK 6 available

On OSX 8 (10.8.x) there is still a JDK 6 provided in /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK. Since .mvn/wrapper/maven-wrapper.jar was compiled with JDK 7, it cannot be loaded but raises the following exception:

Exception in thread "main" java.lang.UnsupportedClassVersionError: org/apache/maven/wrapper/MavenWrapperMain : Unsupported major.minor version 51.0

I see two solutions to the problem:

Change the search order in the mvnw wrapper script: search for newer Oracle JDKs (7 or 8) first since they can handle this (then completely drop JDK 6 for Darwin since it makes no sense!)
Compile the Java classes with JDK 6 to enable running with older JDKs

I would prefer solution No. 2 since this would also allow to use the wrapper for legacy projects which rely on JDK 6 (yes, there are still some users of this out there in the dark!)

Document how to upgrade maven wrapper

It seems maven wrapper 0.2.0 has released.
What is the proper way of upgrading existing maven wrapper?

it seems running this upgrades the local maven wrapper files.
mvn -N io.takari:maven:wrapper

It would be good if this is documented.

launcher does not support maven 2.2.1

i can generate the wrapper just fine

$ mvn -N io.takari:maven:wrapper -Dmaven=2.2.1
[INFO] Scanning for projects...
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Apache Avro Toplevel 1.9.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven:0.3.4:wrapper (default-cli) @ avro-toplevel ---
[INFO] 
[INFO] The Maven Wrapper has been successfully setup for your project.
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS

but when i try to run it:

$ ./mvnw clean
Exception in thread "main" java.lang.RuntimeException: Could not locate the Maven launcher JAR in Maven distribution '/home/user/.m2/wrapper/dists/apache-maven-2.2.1-bin/734vqac49jfbm96jf0vlddftns/apache-maven-2.2.1'.
	at org.apache.maven.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:50)
	at org.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:28)
	at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:122)
	at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:50)

looking at the maven 2.2.1 distribution it doesnt have plexus-classworlds-*.jar which the wrapper expects. instead it has /lib/maven-2.2.1-uber.jar

boot behavior of the script 'mvnw' is out of sync with the original 'mvn'

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.

Allowing specify JDK requirements in the properties

If you fire up the Maven Wrapper with an older JDK you get the dreaded java.lang.UnsupportedClassVersionError error. We should detect the JDK and display a usable error message with instructions for correcting the problem.

Add support for using settings.xml as part of the download process

C:\workspace\Courier\7.18>mvn -N io.takari:maven:wrapper
[INFO] Scanning for projects...
[INFO]
[INFO] Using the builder org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder with a thread count of 1
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building courier 7.18
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven:0.3.3:wrapper (default-cli) @ courier ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.334 s
[INFO] Finished at: 2015-11-25T16:33:56+03:00
[INFO] Final Memory: 17M/981M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.takari:maven:0.3.3:wrapper (default-cli) on project courier: Error installing the maven-wrapper archive. Cannot dete
rmine the type of archive C:\Users\xxx.m2\repository\io\takari\maven-wrapper\0.1.4\maven-wrapper-0.1.4.tar.gz. Input is not in the .gz format ->

C:\Users\xxx.m2\repository\io\takari\maven-wrapper\0.1.4\maven-wrapper-0.1.4.tar.gz

This is not my local repository. It was redefined in ~/.m2/settings.xml.

mvnw with sub-modules

As @dsyer mentioned in #4 mvnw doesn't play well with sub-modules.

I'm currently using this little helper script, a copy of which I drop into every sub-module. It traverses up the directories to find the root project (a directory that contains pom.xml, mvnw, and .mvn/wrapper). It then runs the top level mvnw, passing the sub-module it was executed from and --also-make (to build dependencies as well).

As workarounds go this has been working well for me for the last 10 months or so, but it would be neat if mvnw supported this out of the box.

In it's simplest form "support" could mean mvnw ships this script and provides a way to drop a copy into a sub-module on request (having the script in each module is quite nice in that you can always say ./mvnw ... rather than having to supply the right number of ../....

Alternatively some of this logic could be integrated into mvnw directly so that when run from a sub-directory the relevant maven arguments are injected automatically. The per-module mvnw script could then potentially be replaced with a symlink.

#!/bin/bash
# child-mvnw: Finds the top-level project and invokes a reactor build there

path=""; cd "$(dirname "$0")"
while true; do
  if [ "$PWD" = "/" ]; then echo "Unable to find project root" >&2; exit 1; fi
  path="$(basename "$PWD")/$path"; cd ..
  [ -f pom.xml -a -f mvnw -a -d .mvn/wrapper ] && break
done
exec ./mvnw --projects "${path%/}" --also-make "$@"

If there's interest in this I'd be happy to provide a pull request (for non-Windows platforms at least, don't have a Windows machine on hand to test with), but I wanted to see if anybody else cares about this feature and/or other ideas to approach it.

how to modify maven

This may be a documentation issue. I wasn't able to see how to modify the maven installation downloaded by mvnw. For the regular system-wide maven installation, I usually update it with Guy's excellent "maven color" changes (https://github.com/jcgay/maven-color) which requires switching logback from the "simple" implementation to the "classic" one.

Suggestions?

download maven-wrapper.jar within the script

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.

SSLHandshakeException downloading Maven zip

Hi I'm running ./mvnw inside a Docker container

Downloading https://repo1.maven.org/maven2/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-bin.zip

Exception in thread "main" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1959)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
        at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1514)
        at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:961)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)
        at org.apache.maven.wrapper.DefaultDownloader.downloadInternal(DefaultDownloader.java:73)
        at org.apache.maven.wrapper.DefaultDownloader.download(DefaultDownloader.java:60)
        at org.apache.maven.wrapper.Installer.createDist(Installer.java:64)
        at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:121)
        at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:50)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:397)
        at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:302)
        at sun.security.validator.Validator.validate(Validator.java:260)
        at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
        at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
        at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
        at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1496)
        ... 17 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
        at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
        at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
        at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
        at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
        ... 23 more

But when I've run the java InstallCert utility class.
I have no errors and don't need to install any cert.

java InstallCert repo1.maven.org
Loading KeyStore cacerts...
Opening connection to repo1.maven.org:443...
Starting SSL handshake...

No errors, certificate is already trusted

The wrapper now downloads source files in the .mvn/wrapper directory

Hi,

Starting this morning (and I didn't have builds running for a few days so I think it must be a regression in the latest release), my Travis builds fail because I have a license checking plugin and the Maven wrapper starts to download some source files:

[INFO] Checking licenses...
[WARNING] Missing header in: /home/travis/build/gsmet/hibernate-validator/.mvn/wrapper/MavenWrapperDownloader.java

Is this something expected? I will ignore these files in my license check but it looks like a bug.

Thanks.

Can we get a new release?

The latest release of io.takari:maven on Maven Central was 9 months ago on 26-Oct-2015. I think it's time for a new release so we can use mvn -N io.takari:maven:wrapper instead of copy-pasting files.

(I need a more recent release because of this patch, which fixed maven-wrapper in Cygwin).

Update to Maven 3.5.2 -- fix color issue for Cygwin / MinGW

https://issues.apache.org/jira/browse/MNG-6242

To support color Maven output, update to Maven 3.5.2, and/or update the wrapper scripts along these lines (diff for mvnw):

211a212,219
> # detect cygwin or mingw pseudo-terminal for Jansi
> # workaround for https://github.com/fusesource/jansi-native/issues/11
> if $cygwin || $mingw; then
>   if [ -t 1 ]; then
>     MAVEN_OPTS="-Djansi.passthrough=true $MAVEN_OPTS"
>   fi
> fi
>

How about add document of available environment variable?

In mvnw or mvnw.cmd, we can use a some environment variable:

JAVA_OPTS
MAVEN_OPTS

In my environment, I struggle with http proxy settings.
I have proxy settings in maven settings file e.g. .m2/settings.xml and
environemnt variable http_proxy https_proxy .

But mvnw won't work well. What I needed:

MAVEN_OPTS=-Dhttp.proxyHost=proxyHost \
-Dhttp.proxyPort=8000 \
-Dhttps.proxyHost=proxyHost \
-Dhttps.proxyPort=8000

So, It is good that there are document about using available envrionement variable and
about using mvnw in http proxy envrionment.

May I send PR?

Add feature to download of a specific version of the JDK

Hi!

The first line of the README states that "The Maven Wrapper is an easy way to ensure a user of your Maven build has everything necessary to run your Maven build". However there is a huge thing missing: the JDK itself!
It would be SO cool to be able to specify a given version of the JDK to use during the maven build, and let Maven Wrapper automatically download it. Such a feature would also be very interesting to have reproducible builds (cf. Reproducible/Verifiable Builds on the Apache Maven wiki).
The implementation could reuse JdkGet.

What to you think about such a feature?

Regards

The wrapper writes debug info to stdout when downloading

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.

Issues with M2_HOME on Windows

Seems like people are having problems with M2_HOME settings in Windows. E.g. see https://github.com/rimerosolutions/maven-wrapper-example/issues/3#issuecomment-24521843

Support extensions provisioning

please add wrapper list property

to auto-install maven extensions into lib/ext
i.e. for http://takari.io/book/30-team-maven.html

Wrapper doesn't work in a sub-module

The wrapper doesn't work in a sub-module:

$ mvn -N io.takari:maven:wrapper
$ ./mvnw install
...
[INFO] BUILD SUCCESS
...
$ cd submodule
$ ../mvnw install -X
Error: Could not find or load main class org.apache.maven.wrapper.MavenWrapperMain

mvnw does not handle MAVEN_PROJECTBASEDIR being root of a drive

Using subst to set a drive letter to the folder holding my project and building from that drive letter (T:\)will result in

set MAVEN_PROJECTBASEDIR=T:\

This causes WRAPPER_JAR to be malformed

set WRAPPER_JAR=""T:\\.mvn\wrapper\maven-wrapper.jar""

The java execution then fails with java displaying a usage message.

"C:\Program Files\Java\jdk1.7.0\bin\java.exe"    -classpath ""T:\\.mvn\wrapper\maven-wrapper.jar"" "-Dmaven.multiModuleProjectDirectory=T:\" org.apache.maven.wrapper.MavenWrapperMain  
Usage: java [-options] class [args...]
           (to execute a class)
   or  java [-options] -jar jarfile [args...]
           (to execute a jar file)

Consider using java.home from java output

Unfortunately, which java does not work correctly for some users. For example, for jenv users mvnw won't be able to determine the JAVA_HOME correctly and will print a warning each time it is invoked.

For the purpose of determining JAVA_HOME we use the following script in our projects:

"${JAVA_HOME:-$(java -XshowSettings:properties -version 2>&1 > /dev/null | grep 'java.home' | awk '{print $3}')}"

It works for system installations and for various tools that manage several Java installations.

No newline at end of properties file and unnecessary executable permissions

On Linux, when running the following command:

mvn -N io.takari:maven:wrapper

The file .mvn/wrapper/maven-wrapper.properties does not end with a new line.
The following files have executable permission while it's not needed:
- mvnw.cmd
- .mvn/wrapper/MavenWrapperDownloader.java
- .mvn/wrapper/maven-wrapper.jar
- .mvn/wrapper/maven-wrapper.properties

mvn -N io.takari:maven:wrapper errors out

looks like mvn -N io.takari:maven:wrapper does not currently work see output below

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
Maven home: /usr/local/Cellar/maven/3.5.4/libexec
Java version: 1.8.0_171, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home/jre
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"

output when trying to install the plugin

mvn -N io.takari:maven:wrapper -e
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven/maven-metadata.xml
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven/maven-metadata.xml (507 B at 838 B/s)
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven/0.6.1/maven-0.6.1.pom
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven/0.6.1/maven-0.6.1.pom (2.1 kB at 12 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari/27/takari-27.pom
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari/27/takari-27.pom (14 kB at 49 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven/0.6.1/maven-0.6.1.jar
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven/0.6.1/maven-0.6.1.jar (7.8 kB at 54 kB/s)
[INFO] 
[INFO] ------------------------< com.evctools:evc-dev >------------------------
[INFO] Building evc-dev ${revision}
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- maven:0.6.1:wrapper (default-cli) @ evc-dev ---
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.4.2/maven-wrapper-0.4.2.pom
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.4.2/maven-wrapper-0.4.2.pom (2.4 kB at 12 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari-archiver/0.1.9/takari-archiver-0.1.9.pom
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari-archiver/0.1.9/takari-archiver-0.1.9.pom (1.8 kB at 8.3 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari/15/takari-15.pom
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari/15/takari-15.pom (15 kB at 69 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/graph/takari-graph/0.0.3/takari-graph-0.0.3.pom
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/graph/takari-graph/0.0.3/takari-graph-0.0.3.pom (4.7 kB at 39 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari/14/takari-14.pom
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari/14/takari-14.pom (13 kB at 97 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.4.2/maven-wrapper-0.4.2.jar
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/graph/takari-graph/0.0.3/takari-graph-0.0.3.jar
Downloading from central: https://repo.maven.apache.org/maven2/io/takari/takari-archiver/0.1.9/takari-archiver-0.1.9.jar
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/maven-wrapper/0.4.2/maven-wrapper-0.4.2.jar (48 kB at 212 kB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/takari-archiver/0.1.9/takari-archiver-0.1.9.jar (41 kB at 133 kB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/io/takari/graph/takari-graph/0.0.3/takari-graph-0.0.3.jar (173 kB at 455 kB/s)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.578 s
[INFO] Finished at: 2018-08-01T14:54:26+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.takari:maven:0.6.1:wrapper (default-cli) on project evc-dev: Error installing the maven-wrapper archive.: https://repo1.maven.org/maven2/io/takari/maven-wrapper/1.0.0/maven-wrapper-1.0.0.tar.gz -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal io.takari:maven:0.6.1:wrapper (default-cli) on project evc-dev: Error installing the maven-wrapper archive.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error installing the maven-wrapper archive.
    at io.takari.maven.plugins.WrapperMojo.execute (WrapperMojo.java:67)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: java.io.FileNotFoundException: https://repo1.maven.org/maven2/io/takari/maven-wrapper/1.0.0/maven-wrapper-1.0.0.tar.gz
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream0 (HttpURLConnection.java:1890)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream (HttpURLConnection.java:1492)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream (HttpsURLConnectionImpl.java:263)
    at org.apache.maven.wrapper.DefaultDownloader.downloadInternal (DefaultDownloader.java:73)
    at org.apache.maven.wrapper.DefaultDownloader.download (DefaultDownloader.java:60)
    at io.takari.maven.plugins.WrapperMojo.execute (WrapperMojo.java:57)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
[ERROR] 
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

error: input is not in gz format

I do mvn -N io.takari:maven:wrapper -Dmaven=3.3.9 (windows7, gitbash, maven 3.3.9)

and get:

Failed to execute goal io.takari:maven:0.4.1:wrapper (default-cli) on project bpa-platform: 
Error installing the maven-wrapper archive. Cannot determine the type of archive ...\.m2\repository\io\takari
\maven-wrapper\0.2.1\maven-wrapper-0.2.1.tar.gz. Input is not in the .gz format -> [Help 1]

ideas?

Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '...\vsts-agent-win-x64-2.131.0\_work\r7\a\Content\settings.xml'

I am using the below release configuration and by using it i am executing the .exe file from cmd. In the release configration, for cmd i set 'Tool' to "$(System.DefaultWorkingDirectory)\_23 April Config-clone\drop-2\P.B.Dep\bin\Sumit\P.B.D.exe"

But I'm getting the error:
Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\droVM123\Downloads\vsts-agent-win-x64-2.131.0\_work\r7\a\Content\settings.xml'on deployment.

Here is the error log for the cmd run:

2018-04-26T08:23:05.2636416Z ##[section]Starting: Run
2018-04-26T08:23:05.2639275Z ==============================================================================
2018-04-26T08:23:05.2639500Z Task         : Command Line
2018-04-26T08:23:05.2639586Z Description  : Run a command line with arguments
2018-04-26T08:23:05.2639698Z Version      : 1.1.3
2018-04-26T08:23:05.2639778Z Author       : Microsoft Corporation
2018-04-26T08:23:05.2639870Z Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=613735)
2018-04-26T08:23:05.2639991Z ==============================================================================
2018-04-26T08:23:05.2725561Z ##[command]"C:\Users\droVM123\Downloads\vsts-agent-win-x64-2.131.0\_work\r7\a\_23 April Config-clone\drop-2\P.B.Dep\bin\Sumit\P.B.D.exe" 
2018-04-26T08:23:05.6906148Z Exception: System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\droVM123\Downloads\vsts-agent-win-x64-2.131.0\_work\r7\a\Content\settings.xml'.
2018-04-26T08:23:05.7260207Z ##[error]Process completed with exit code 1.
2018-04-26T08:23:05.7282176Z ##[section]Finishing: Run

Other info:
The issue is only for the release. I'm using VSTS and have configured a server(Windows Server 2012 R2) for the build + release & uses MSBuid 14 for the build.

Use of bashisms make this script fail in minimal /bin/sh implementations like dash

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.

Fails to load maven-wrapper.jar on Windows if there is a space in the path

For example:

C:\Users\Spaces User\Project> .\mvnw clean
'#' is not recognized as an internal or external command,
operable program or batch file.
Error: Could not find or load main class User\Project\.mvn\wrapper\maven-wrapper.jar

Support MAVEN_ARGS

Hi!

It would be nice if Maven Wrapper would support MAVEN_ARGS:
https://github.com/apache/maven/blob/811b8f52f9dd897267f7a57656f84810827a3121/apache-maven/src/bin/mvn#L34

it's very handy to set some defaults.

Thanks!

explicitly enable http proxies

when building under Linux (in this case Ubuntu Linux) using

./mvnw clean verify

from behind a proxy, the maven/java stuff will not use the system proxies unless explicitly told to do so, which is a problem when maven tries to download the jars it needs :-)

please also see original issue here: pmd/pmd#498

I'm guessing you are going to tell me I need to log a bug report against maven itself, but at least this is one step forward :-)

Configurable maven install directory

My CI env does not allow the build to use its home directory, and maven wrapper is current unpack maven under ~/.m2

place 'maven-wrapper.jar' in ${user.home}/.m2/wrapper

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.

Means to check current maven wrapper version

Is there any way to check current version of maven wrapper?

maybe ./mvnw --version to include maven wrapper version??

Misleading error message in case maven zip file is corrupt

Given that the maven library in, e.g., ~/.m2/wrapper/dists/apache-maven-3.5.2-bin/28qa8v9e2mq69covern8vmdkj0/apache-maven-3.5.2-bin.zip is corrupt, java.util.zip.ZipFile stops with this misleading error message:

    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:225)
    at java.util.zip.ZipFile.<init>(ZipFile.java:155)
    at java.util.zip.ZipFile.<init>(ZipFile.java:169)
    at org.apache.maven.wrapper.Installer.unzip(Installer.java:161)
    at org.apache.maven.wrapper.Installer.createDist(Installer.java:78)
    at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:121)
    at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:55)```

It suggests that the error is on the level of the filesystem, however, the contents of the file is not a correct zip byte stream. A better way of responding would be to indicate that the zip file could not be expanded like "error in expanding zip file".

Stale maven-wrapper.jar bundled with maven-wrapper-{version}.tar.gz since 0.1.4

When building master, which is currently at 0.1.7-SNAPSHOT, a maven-wrapper.jar is magically installed in target/maven-wrapper-0.1.7-SNAPSHOT/.mvn/wrapper/maven-wrapper.jar. DEBUG logging doesn't indicate anything useful. The contents are always stale with a timestamp of 4/3/2015 1:07 AM.

META-INF/MANIFEST.MF:

Manifest-Version: 1.0
Implementation-Title: maven-wrapper
Implementation-Version: 0.1.2-SNAPSHOT
Implementation-Vendor-Id: io.takari
Build-Jdk: 1.7.0_67
Built-By: jvanzyl
Specification-Title: maven-wrapper
Created-By: Takari Inc.
Specification-Version: 0.1.2-SNAPSHOT
Archiver-Version: Provisio Archiver

This jar is added to target/maven-wrapper-0.1.7-SNAPSHOT.tar.gz which is later installed in the local repository. I've found that target/maven-wrapper-0.1.7-SNAPSHOT.jar and target/maven-wrapper-0.1.7-SNAPSHOT-sources.jar are not stale. The other 3 files in target/maven-wrapper-0.1.7-SNAPSHOT.tar.gz (mvnw, mvnw.cmd and maven-wrapper.properties) are not stale.

Incidentally, all versions since 0.1.2 (i.e. 0.1.4, 0.1.5 and 0.1.6) in Maven Central contain this stale jar.

Extraneous output breaks parsing Maven output

This line in mvnw: 2fea7af#diff-7f6d424362f5b03d9b91a80a1e43eefeR200

Breaks scripts that may have been trying to parse the output of a Maven command kicked off with maven-wrapper (e.g. mvn help:execute ... to extract properties from a project) by introducing an unexpected, non-maven / non-formatted line of output.

It looks like it was just left in after adding a new feature...?

Please remove it.

Allow specifying Maven extensions

Maven extensions can be dropped in the MVN_HOME/lib/ext directory. They are very useful for things like custom wagons (S3, ...). It would be great to be able to specify the Maven coordinates of the extension jars that should be downloaded and dropped in that directory.

Configuring maven wrapper local repository

I already configured local repository using in setting.xml file under my M2_HOME/conf folder. it is <localRepository>D:/Programs/maven_repository</localRepository> . With mvn command, custom local repository works fine. but the mvnw command ( i am on windows 7 64 bit with maven 3.5.0), always uses default local repository, ${user.home}/.m2 ( C:\Users\prism.m2 in my case). Is there any option to use custom local repository with maven wrapper?

What about a default settings.xml?

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?