You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It should be possible to set a specific Maven version to use with mvn. For that it should be optionally possible to download also Maven from some Apache mirror (https://maven.apache.org/download.cgi) after downloading Java and then use that mvn version.
While this seems like feature creep, I agree that it would be useful to specify versions for both maven and gradle. This is especially useful for using EA and RC versions (e.g. Gradle support JDK 13 arrived ~2 months after JDK 13, but gradle 6.0 release candidates were available). For ease of use, specifying a version would be a good first option via e.g. gradleVersion or mvnVersion (which would then choose from a well known curated source for either maven or gradle), and supplying a URI or a file should certainly be an option (similar to the jdkFile option).
I had some code for this so created a PR. We'll see what maintainers think about it.
I'm not really sure if these customisations should be in their own actions(setup-gradle, setup-maven) which would be easy to do but it's a bit pita to use different actions as you mostly likely use maven/gradle with this action. Though default versions are available from agent(at least for ubuntu).
Very cool! And I think the spelling you chose (e.g. maven-version, gradle-version) fits cleanly and naturally with the existing java-version spelling.
👍
That way you can build the project locally and aren't depending on the GitHub action to set up everything for you.
Over at Apache Commons we have 30 Components, each it's own Maven build in it's own repository, and I would not want to duplicate these wrapper files all over the place. It seems to me that a maven setup action is the most modular and flexible.
Reacted by Greg Chabala, Kevin S. Clarke, Richard Eckart de Castilho, David Phillips and Sergey Zolotaryov
Why not use the Gradle wrapper or Maven wrapper instead?
For instance, compatibility tests require different versions in CI.
I'm maintaining a Maven extension (https://github.com/vackosar/gitflow-incremental-builder) and I need to check that nothing breaks with older Maven versions.
Maven wrapper does not seem to be right choice for this.
I see this issue labels moved from enhancement into feature request which makes me think we are far from seeing the solution implemented (I hope I'm wrong in the label understanding).
What is the process to "certified" or "verify" an action? or what other alternatives do we currently have to try setting specific maven version for multi-branch projects?
I would like to bring this issue up again, as this is a feature I would like to use in my setup. I don't want just to have build with different JDK versions, but also with more than one Maven version.
Please consider again to allow users of this action to choose the Maven version to use for the build. This feature will be required at least with the release of Maven 4.
Reacted by jeacott1, Kevin S. Clarke and Per Thomas Lundal
Please consider again to allow users of this action to choose the Maven version to use for the build. This feature will be required at least with the release of Maven 4.
If your build relies on a specific version of Maven, then you should express that in your repository with the Maven wrapper downloading the exact version you need.
In my case the Maven wrapper will not help, as I have to test my stuff with various Maven versions to detect incompatibilities in my software between Maven versions.
Unfortunately this will not help, as we have a whitelist of actions we are allowed to use.
Asking maintainers of an action that is whitelisted by your organization to include features available on non-whitelisted (by your org) actions seems a very weird way to workaround the inevitable conversation you should be having with your bosses.
Asking maintainers of an action that is whitelisted by your organization to include features available on non-whitelisted (by your org) actions seems a very weird way to workaround the inevitable conversation you should be having with your bosses.
Maybe, maybe not. I see it like this: This action provides Java and Maven. Java is configurable, Maven not. For me it would be total fine to remove the Maven part and to provide it as dedicated action. Would be even a better separation of concerns.
Asking maintainers of an action that is whitelisted by your organization to include features available on non-whitelisted (by your org) actions seems a very weird way to workaround the inevitable conversation you should be having with your bosses.
Maybe, maybe not. I see it like this: This action provides Java and Maven. Java is configurable, Maven not. For me it would be total fine to remove the Maven part and to provide it as dedicated action. Would be even a better separation of concerns.
Well, that makes sense indeed :-) A key part of this is that this would be an official GH action, not a random 3rd party action.
This action provides a JDK. Maven is preinstalled on the action runners. 😉
It sounds like you would best write your own action for installing arbitrary versions of Maven, maybe forked from one of the existing actions from the market place.
@obfischer you might be surprised but this action configures Maven in a way that such configuration will be picked up by Maven Wrapper, which then, can be almost any version of Maven.
Activity
giltene commentedon Jan 7, 2020
+1
While this seems like feature creep, I agree that it would be useful to specify versions for both maven and gradle. This is especially useful for using EA and RC versions (e.g. Gradle support JDK 13 arrived ~2 months after JDK 13, but gradle 6.0 release candidates were available). For ease of use, specifying a version would be a good first option via e.g. gradleVersion or mvnVersion (which would then choose from a well known curated source for either maven or gradle), and supplying a URI or a file should certainly be an option (similar to the jdkFile option).
Add support for maven/gradle versions
jvalkeal commentedon Jan 17, 2020
I had some code for this so created a PR. We'll see what maintainers think about it.
I'm not really sure if these customisations should be in their own actions(setup-gradle, setup-maven) which would be easy to do but it's a bit pita to use different actions as you mostly likely use maven/gradle with this action. Though default versions are available from agent(at least for ubuntu).
giltene commentedon Jan 17, 2020
Very cool! And I think the spelling you chose (e.g. maven-version, gradle-version) fits cleanly and naturally with the existing java-version spelling.
👍
martinpaljak commentedon Feb 18, 2020
Would love to see this being available!
brunoborges commentedon Apr 1, 2020
I think Maven and/or Gradle support should be provided in separate actions.
joschi commentedon May 24, 2020
@kwin @giltene Why not use the Gradle wrapper or Maven wrapper instead?
That way you can build the project locally and aren't depending on the GitHub action to set up everything for you.
garydgregory commentedon Aug 15, 2020
Over at Apache Commons we have 30 Components, each it's own Maven build in it's own repository, and I would not want to duplicate these wrapper files all over the place. It seems to me that a maven setup action is the most modular and flexible.
brunoborges commentedon Aug 19, 2020
@garydgregory our recommendation is that developers use a separate Action for Maven. There are a few options already available on the Marketplace [1].
[1] https://github.com/marketplace?type=actions&query=maven
garydgregory commentedon Aug 19, 2020
Thank you!
famod commentedon Jan 24, 2021
Heads up:
In case anyone is using https://github.com/stCarolas/setup-maven, you will most likely run into
M2_HOMEenv var being set although it not used by newer Maven versions anymore: actions/runner-images#2534@joschi
For instance, compatibility tests require different versions in CI.
I'm maintaining a Maven extension (https://github.com/vackosar/gitflow-incremental-builder) and I need to check that nothing breaks with older Maven versions.
Maven wrapper does not seem to be right choice for this.
cesarhernandezgt commentedon Feb 12, 2021
Hi @brunoborges @maxim-lobanov
This was useful in Apache-related projects, now since early 2021 the usage of non-verified actions is discouraged, and that basically leaves an empty result set when you want to search for Maven verified Actions.
https://github.com/marketplace?query=maven&type=actions&verification=verified
I see this issue labels moved from
enhancementintofeature requestwhich makes me think we are far from seeing the solution implemented (I hope I'm wrong in the label understanding).What is the process to "certified" or "verify" an action? or what other alternatives do we currently have to try setting specific maven version for multi-branch projects?
5 remaining items
obfischer commentedon Dec 21, 2021
I would like to bring this issue up again, as this is a feature I would like to use in my setup. I don't want just to have build with different JDK versions, but also with more than one Maven version.
Please consider again to allow users of this action to choose the Maven version to use for the build. This feature will be required at least with the release of Maven 4.
brunoborges commentedon Dec 22, 2021
I'm personally not in favor of this action having any further functionality other than setting up Java (the JDK, to be more specific).
Frankly, if this action ever gets a v3, it should not carry and feature that is not related to this particular goal.
An Action specifically for Maven should be born, for clear separation of concerns.
Plus, with composite actions now, I'd say this would be ideal.
joschi commentedon Dec 22, 2021
The Maven Wrapper exists, now even as an official plugin: https://maven.apache.org/wrapper/maven-wrapper-plugin/
If your build relies on a specific version of Maven, then you should express that in your repository with the Maven wrapper downloading the exact version you need.
As an alternative, there are multiple actions on the marketplace which allow setting up Maven in GitHub Actions workflows:
https://github.com/marketplace?type=actions&query=maven
obfischer commentedon Dec 22, 2021
In my case the Maven wrapper will not help, as I have to test my stuff with various Maven versions to detect incompatibilities in my software between Maven versions.
Unfortunately this will not help, as we have a whitelist of actions we are allowed to use.
brunoborges commentedon Dec 22, 2021
Asking maintainers of an action that is whitelisted by your organization to include features available on non-whitelisted (by your org) actions seems a very weird way to workaround the inevitable conversation you should be having with your bosses.
obfischer commentedon Dec 22, 2021
Maybe, maybe not. I see it like this: This action provides Java and Maven. Java is configurable, Maven not. For me it would be total fine to remove the Maven part and to provide it as dedicated action. Would be even a better separation of concerns.
garydgregory commentedon Dec 22, 2021
Well, that makes sense indeed :-) A key part of this is that this would be an official GH action, not a random 3rd party action.
joschi commentedon Dec 22, 2021
This action provides a JDK. Maven is preinstalled on the action runners. 😉
It sounds like you would best write your own action for installing arbitrary versions of Maven, maybe forked from one of the existing actions from the market place.
brunoborges commentedon Dec 23, 2021
While this action does not install Maven, it does have features for configuring it.
That alone is more than this action should be doing.
I wish we can separate that to a new action, along with a v3 for this one without build tool related features.
Donnadam commentedon Dec 23, 2021
obfischer commentedon Dec 23, 2021
I think the documentation should mention, that this action relies on the Maven version installed on the runner.
I will file an pull request with some notes.
brunoborges commentedon Dec 24, 2021
@obfischer you might be surprised but this action configures Maven in a way that such configuration will be picked up by Maven Wrapper, which then, can be almost any version of Maven.
joschi commentedon Dec 24, 2021
I'll just leave this here for your consideration:
Donnadam commentedon Dec 24, 2021