Cannot find maven executable

[varijkapil13]

Hi,

Thank you for the great plugin.
I am trying to integrate this in an existing project and I am facing a problem how the pre-commit is generated.

The Pre-Commit Hook script that is generated for the project looks like this:

#!/bin/bash
set -e
"<project-path>/mvn" -f "<project-path>/pom.xml" com.cosmium.code:git-code-format-maven-plugin:on-pre-comit

The problem is how path to maven executable is generated <project-path>/mvn. When the pre-commit hook is called, maven cannot be found on this path and the hook fails.

I tried using a .mvn folder in root directory of the project with wrapper folder and then a MavenWrapperDownloader.java (I copied it from a Spring Project), but this did not seem to help.

Is there a way we can disable this? So I can say write mvn instead of <project-path>/mvn in the bash script?

If not, would you be open to accepting a PR for this? probably also for a previous version of the plugin? (v2.7)

Thanks!

EDIT: I think this is related to tooling. When I run mvn clean install via IntelliJ and IntelliJ uses bundled maven, then the plugin do not get the correct path to maven. But I think there still should be an option to configure this, for let's say teams where updating IDEs for everyone is not desired. Anyways, I would be happy to submit a PR if this is something that the maintainers would consider as an option

[reda-alaoui]

Hi @varijkapil13 ,

Is there a way we can disable this? So I can say write mvn instead of /mvn in the bash script?

Not currently

If not, would you be open to accepting a PR for this? probably also for a previous version of the plugin? (v2.7)

A PR would be welcome. But why not use the version 3?

[varijkapil13]

A PR would be welcome. But why not use the version 3?

Great I will start working on it.

Version 3 requires, according to the docs, maven on JDK 11. And I receive the following error:

[ERROR] Failed to execute goal com.cosium.code:git-code-format-maven-plugin:3.0:on-pre-commit (default-cli) on project otp-service: Execution default-cli of goal com.cosium.code:git-code-format-maven-plugin:3.0:on-pre-commit failed: An API incompatibility was encountered while executing com.cosium.code:git-code-format-maven-plugin:3.0:on-pre-commit: java.lang.UnsupportedClassVersionError: com/google/googlejavaformat/java/FormatterException has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

This is currently a pain point for us. We have CI pipelines and all developers machines using JDK 8. We are planning to update this, but we are not there yet.

Therefore, it would be useful if this can land in version 2.8 and 3.1 for example

[reda-alaoui]

Ok no problem for version 2.

[GDIBass]

Bump! Any luck with this PR?

[m-gora]

Strange, for me it generated the hook like this:

#!/bin/bash
set -e
"/usr/share/maven/bin/mvn" -f "/home/......../pom.xml" com.cosium.code:git-code-format-maven-plugin:on-pre-commit

On
Ubuntu 20.04
JDK 11
Maven 3.6.3.

Currently investigating on this, since a colleague has a problem on win10 that the hook script can not be generated with the same error message.

[varijkapil13]

Hi @GDIBass
sorry for the late reply, I was hoping for a little help on the PR but did not get any. In the meanwhile also did not check back again and got busy with personal stuff.
We opted for a different solution. Instead of using this plugin, we are now using spotless and also updated to Java 11.

If you are interested in this feature, maybe you can continue on where i left? Unfortunately, I wouldn't be able to do complete this.

[GDIBass]

No worries at all, and understood. Thank you for the reply! Not sure how we'll proceed at the moment, but we'll have to make some sort of move if this doesn't get any traction.

[reda-alaoui]

Hi everyone,

Sorry for having been unresponsive on the pull request. Had a lot to do on other topics.
If someone wants to take it to the finish line, I will try to be more responsive.

[GDIBass]

What would be needed to carry #72 across the finish line?

[montss]

The current implementation is a bit weird, the standard way of installing maven whether on Linux based OS or in Windows, is just adding the maven directory to the Path environment variable, why maven.home system property is being checked here?

In my case,
$ mvn -v
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: C:\Work\mvn
Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: C:\Program Files\Eclipse Adoptium\jdk-11.0.13.8-hotspot
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

The plugin didn't work, and failed with No valid maven executable found ! error

[reda-alaoui]

is just adding the maven directory to the Path environment variable, why maven.home system property is being checked here?

Because you could have multiple versions/binaries of Maven on your system.

[montss]

Because you could have multiple versions/binaries of Maven on your system.
That defies the goal here I would say, running a maven plugin should be a matter of just adding it to the pom, and configure it in the pom only

The standard maven installation requires a JAVA_HOME env variable and to add maven directory to the PATH env variable nothing more.

If more steps is needed to run this plugin could you at least add them to the Readme file.

[reda-alaoui]

to add maven directory to the PATH env variable nothing more.

Adding a binary to PATH is never required.

That defies the goal here I would say, running a maven plugin should be a matter of just adding it to the pom, and configure it in the pom only

We can't dumb down the issue like this. People can have multiple binaries of Maven on the same machine. CI machines are the first example coming to mind. The solution must cover those cases.

[reda-alaoui]

should be a matter of just adding it to the pom

Who wouldn't agree on that?