Skip to content

Allow to customize Maven version #40

Closed

Description

@kwin

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.

Activity

  1. giltene commented on Jan 7, 2020

    @giltene
    Contributor

    +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).

  2. added a commit that references this issue on Jan 17, 2020
    7b8939a
  3. jvalkeal commented on Jan 17, 2020

    @jvalkeal

    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).

  4. giltene commented on Jan 17, 2020

    @giltene
    Contributor

    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.
    👍

  5. martinpaljak commented on Feb 18, 2020

    @martinpaljak

    Would love to see this being available!

  6. brunoborges commented on Apr 1, 2020

    @brunoborges
    Contributor

    I think Maven and/or Gradle support should be provided in separate actions.

  7. joschi commented on May 24, 2020

    @joschi
    Contributor

    @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.

  8. garydgregory commented on Aug 15, 2020

    @garydgregory

    @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.

    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.

  9. brunoborges commented on Aug 19, 2020

    @brunoborges
    Contributor

    @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

  10. garydgregory commented on Aug 19, 2020

    @garydgregory

    Thank you!

  11. famod commented on Jan 24, 2021

    @famod

    our recommendation is that developers use a separate Action for Maven

    Heads up:
    In case anyone is using https://github.com/stCarolas/setup-maven, you will most likely run into M2_HOME env var being set although it not used by newer Maven versions anymore: actions/runner-images#2534

    @joschi

    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.

  12. cesarhernandezgt commented on Feb 12, 2021

    @cesarhernandezgt

    Hi @brunoborges @maxim-lobanov

    I think Maven and/or Gradle support should be provided in separate actions.

    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 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?

  13. 5 remaining items

  14. obfischer commented on Dec 21, 2021

    @obfischer

    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.

  15. brunoborges commented on Dec 22, 2021

    @brunoborges
    Contributor

    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.

  16. joschi commented on Dec 22, 2021

    @joschi
    Contributor

    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.

    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

  17. obfischer commented on Dec 22, 2021

    @obfischer

    The Maven Wrapper exists, now even as an official plugin: https://maven.apache.org/wrapper/maven-wrapper-plugin/

    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.

    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

    Unfortunately this will not help, as we have a whitelist of actions we are allowed to use.

  18. brunoborges commented on Dec 22, 2021

    @brunoborges
    Contributor

    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.

  19. obfischer commented on Dec 22, 2021

    @obfischer

    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.

  20. garydgregory commented on Dec 22, 2021

    @garydgregory

    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.

  21. joschi commented on Dec 22, 2021

    @joschi
    Contributor

    This action provides Java and Maven.

    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.

  22. brunoborges commented on Dec 23, 2021

    @brunoborges
    Contributor

    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.

  23. Donnadam commented on Dec 23, 2021

    @Donnadam
  24. obfischer commented on Dec 23, 2021

    @obfischer

    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.

  25. brunoborges commented on Dec 24, 2021

    @brunoborges
    Contributor

    @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.

  26. joschi commented on Dec 24, 2021

    @joschi
    Contributor

    I'll just leave this here for your consideration:

    # mvn -q -N io.takari:maven:0.7.7:wrapper -Dmaven=3.5.4 && ./mvnw -v
    Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
    Maven home: /path/to/.m2/wrapper/dists/apache-maven-3.5.4-bin/4lcg54ki11c6mp435njk296gm5/apache-maven-3.5.4
    Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: /path/to/.asdf/installs/java/temurin-11.0.13+8
    Default locale: de_DE, platform encoding: UTF-8
    OS name: "mac os x", version: "11.6.1", arch: "x86_64", family: "mac"
    
    # mvn -q -N io.takari:maven:0.7.7:wrapper -Dmaven=3.6.3 && ./mvnw -v
    Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
    Maven home: /path/to/.m2/wrapper/dists/apache-maven-3.6.3-bin/1iopthnavndlasol9gbrbg6bf2/apache-maven-3.6.3
    Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: /path/to/.asdf/installs/java/temurin-11.0.13+8
    Default locale: de_DE, platform encoding: UTF-8
    OS name: "mac os x", version: "11.6.1", arch: "x86_64", family: "mac"
    
    # mvn -q -N io.takari:maven:0.7.7:wrapper -Dmaven=3.8.4 && ./mvnw -v
    Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
    Maven home: /path/to/.m2/wrapper/dists/apache-maven-3.8.4-bin/52ccbt68d252mdldqsfsn03jlf/apache-maven-3.8.4
    Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: /path/to/.asdf/installs/java/temurin-11.0.13+8
    Default locale: de_DE, platform encoding: UTF-8
    OS name: "mac os x", version: "11.6.1", arch: "x86_64", family: "mac"
    
  27. Donnadam commented on Dec 24, 2021

    @Donnadam
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestNew feature or request to improve the current logic

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions