rimerosolutions / maven-wrapper Goto Github PK

At some point support for older EOL JDK versions should be dropped.

This will remove some boiler pate code.

> .\mvnw.bat clean

ERROR: M2_HOME is set to an invalid directory.
M2_HOME = "c:\person-directory\.."
Please set the M2_HOME variable in your environment to match the
location of the Maven installation

Using:

            <plugin>
                <groupId>com.rimerosolutions.maven.plugins</groupId>
                <artifactId>wrapper-maven-plugin</artifactId>
                <version>0.0.1</version>
            </plugin>

If the distribution repository is a complete Maven repository then along with the Maven binary will be various checksum files (e.g. apache-maven-3.3.9-bin.tar.gz.md5). If present (and/or also directed to) one of these checksums should be downloaded and used to verify the correctness of the binary artifact. Although this has not been a major issue it has bitten us twice already. The verification logic could be added as a step in the Installer.

See: https://repository.apache.org/content/repositories/releases/org/apache/maven/apache-maven/3.3.9/

M2_HOME is supposed to be an optional environment variable but mvnw.bat fails if M2_HOME is not specified:

C:\dev\maven-wrapper-example>mvnw clean

ERROR: M2_HOME is set to an invalid directory.
M2_HOME = "C:\dev\maven-wrapper-example\.."
Please set the M2_HOME variable in your environment to match the
location of the Maven installation

Looking into how the wrapper works, it looks like M2_HOME shouldn't/needn't be set anyway, as you want M2_HOME to point at the location of the wrapper installed copy of Maven; e.g. C:\Users\user.name\.m2\wrapper\dists\apache-maven-3.0.3-bin\dlbgrbn1p3np3ndji3k14guoe\apache-maven-3.0.3.

Related issue https://github.com/rimerosolutions/maven-wrapper-example/issues/3

We started out using the Apache repository as specified in the example but this seemed to experience regular outages. One of the reasons we switched to Maven Wrapper was for more consistent builds across developer and build systems. The outages in the Apache repository were causing automated build failures which undermined our goals.

We switched to the Ibiblio mirror and things improved. However, today the Ibiblio mirror seems to be experiencing problems. Instead of switching back to the Apache repository we would like to be able to specify multiple distribution URIs and only fail the build if none of these are accessible.

If I get some time I will take a look at this myself, but I wanted to file the issue for tracking and to see if there were any other thoughts. In broad strokes the change would look like this:

• Extend MavenWrapperMojo to also support a list of distribution URIs.
• Convert WrapperConfiguration from a single base distribution to a list of base distributions. Encode the base distribution URIs into the wrapper properties file.
• Modify WrapperExecutor to support reading multiple distribution URIs from the wrapper properties file.
• Modify Installer to support downloading from multiple distribution URIs.

When running with Maven 3.3.1 it exits with:

-Dmaven.multiModuleProjectDirectory system propery is not set. Check $M2_HOME environment variable and mvn script match

The only way to fix this is to add this to the Windows batch file:
set MAVEN_OPTS=%MAVEN_OPTS% -Dmaven.multiModuleProjectDirectory=%CD%

and this to the linux script:
MAVEN_OPTS="$MAVEN_OPTS -Dmaven.multiModuleProjectDirectory=$PWD"

If the path has spaces (eg user name has spaces like c:\users\John Smith) the mvnw script will fail to run

Here's a test with the project dir having a space

lq@debiandev:~/space test$ ./mvnw clean build
Error: Could not find or load main class test

With this and Issue #5 is there any reason you can't use the the official batch and sh scripts or wrap them in some way? That way this plugin would be future-proof and means Apache deals with the hard, weird environment support

Hi.

The wrapper does not load any properties placed in a ./maven.properties file. This is due to a bug in the following code in org.apache.maven.wrapper.MavenWrapperMain:

    private static File rootDir( File wrapperJar )
    {
        return wrapperJar.getParentFile().getParentFile().getParentFile();
    }

Stepping through the wrapper with a debugger, rootDir is set incorrectly:

static = org.apache.maven.wrapper.MavenWrapperMain
args = {java.lang.String[1]@80}
wrapperJar = {java.io.File@94}"C:\dev\maven-wrapper-example\maven\maven-wrapper.jar"
propertiesFile = {java.io.File@107}"C:\dev\maven-wrapper-example\maven\maven-wrapper.properties"
rootDir = {java.io.File@109}"C:\dev"

In this example, rootDir should be "C:\dev\maven-wrapper-example" but it's actually set to "C:\dev". I think the rootDir method is assuming that the jar file is nested two directories deep in the codebase but in the maven-wrapper-example codebase (and in the mvnw.bat) the jar file is nested only one directory deep.

I'm guessing this arises from a difference between Gradle Wrapper and Maven Wrapper. Gradle Wrapper places its jar file under ./gradle/wrapper/gradle-wrapper.jar but Maven Wrapper places its jar file under ./maven/maven-wrapper.jar (one directory deep rather than two directories deep). The bug can be fixed by removing one call to getParentFile in the rootDir method:

    private static File rootDir( File wrapperJar )
    {
        return wrapperJar.getParentFile().getParentFile();
    }

Summary
The release often fails on Sonatype with a signature validation failure. Artifacts must be signed for Maven releases (non-snapshot builds).

Details
When it's time to push an official release to the remote Sonatype repository, the signature validation fails with the following message Failed: Signature Validation.

However, when checking locally the signature files with gpg --verify, everything seems ok...

The problem only started recently, it could be related to many things such as a GPG plugin issue or an incompatibility with something related to Sonatype validation.

Impacts
To be able to publish, many attempts are required with some weird POM changes that should not be needed at all...

Related issues
There are couple of tickets on Sonatype JIRA issue tracker such as this one: https://issues.sonatype.org/browse/OSSRH-6664.

Need to see if some of the code can be simplified for maintenance purposes.
Remove obsolete or unused settings, create issues for enhancements if relevant.

This is not a big application, it's not necessarily as straightforward as it could be.

When there's a new release, it's important to highlight the nature of the changes.

What is new? Why would you upgrade? What are the benefits and/or impacts?

Maven allows you to specify the location of the pom.xml file by using the -f argument. The directory of the pom file is also considered the base directory of the project.

 -f,--file <arg>                        Force the use of an alternate POM
                                        file (or directory with pom.xml).

Currently, the wrapper consider the project directory to be MAVEN_BASEDIR if set or else the first directory along the path containing a .mvn directory.

https://github.com/rimerosolutions/maven-wrapper/blob/master/mvnw#L219

It would be useful if the wrapper could detect and use the value of -f (if specified) as the project directory. This would make invoking Maven via the wrapper from another directory transparent vs just running Maven (e.g. running from /foo for a project in /bar by mvn -f /bar/pom.xmlvs//mvnw -f /bar/pom.xml`).

An alternative, would be to start the directory walk in the directory containing the mvnw script instead of the current working directory. Although it's possible there are cases where the user wants the opposite behavior (e.g. shared mvnw script).

In a multi-module codebase with pom.xml files in subdirectories, the maven wrapper does not work. The fix is to make the path to the maven-wrapper.jar be relative to the directory containing the mvnw script instead of relative being relative to the current/working directory. The fix looks like this:

mvnw.bat

@@ -144,7 +111,7 @@
 SET MAVEN_JAVA_EXE="%JAVA_HOME%\bin\java.exe"

 @REM -- Regular WinNT shell
-set WRAPPER_JAR="".\maven\maven-wrapper.jar""
+set WRAPPER_JAR=%~dp0maven\maven-wrapper.jar
 goto runm2

 @REM Start MAVEN2

mvnw

@@ -164,8 +164,10 @@
     CLASSPATH=`cygpath --path --windows "$CLASSPATH"`
 fi

+DIR=`dirname "$0"`
+
 exec "$JAVACMD" \
   $MAVEN_OPTS \
   -classpath "\
-./maven/maven-wrapper.jar" \
+$DIR/maven/maven-wrapper.jar" \
   ${WRAPPER_LAUNCHER} "$@"