Repository navigation
Cannot find maven executable #71
Description
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-comitThe 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
Activity
reda-alaoui commentedon Jun 1, 2021
Hi @varijkapil13 ,
Not currently
A PR would be welcome. But why not use the version 3?
varijkapil13 commentedon Jun 1, 2021
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.0This 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 commentedon Jun 1, 2021
Ok no problem for version 2.
GDIBass commentedon Sep 8, 2021
Bump! Any luck with this PR?
m-gora commentedon Oct 1, 2021
Strange, for me it generated the hook like this:
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 commentedon Oct 7, 2021
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 commentedon Oct 7, 2021
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 commentedon Oct 7, 2021
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 commentedon Oct 28, 2021
What would be needed to carry #72 across the finish line?
montss commentedon Jan 20, 2022
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 commentedon Dec 18, 2022
Because you could have multiple versions/binaries of Maven on your system.
montss commentedon Jan 24, 2023
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 commentedon Jan 24, 2023
Adding a binary to PATH is never required.
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 commentedon Jan 24, 2023
Who wouldn't agree on that?
rohitdev commentedon Jan 3, 2024
I was trying to run the project in Eclipse and faced this issue.
I passed
-Dmaven.home={maven install path change as necessary to your installation}/apache-maven-3.9.4to the VM arguments for the maven build run confuigurationand it worked.