Something about putting maven-specific things into a generic setup-java action seems wrong. Can you elaborate on what is wrong with the "option 2" solution to the problem? That one seems to work without needing anything to change in setup-java, and without introducing username/password options to the action that have no actual use within it (just to propagate them to later users). If we really need that, perhaps it should be in a separate setup-username-and-password action?

Initially I was thinking this should go into a separate action but we want packaging to work on work out of the box, and Maven is the de-facto package ecosystem for Java. This can also be configured to work with Gradle since they use the same registry.

In option 1, you would also need to update action.yml to specify the input parameters and provide them with descriptions and set them as not-required. Having username and password as extra input is fine as long as it's optional and doesn't break existing workflows. I'm leaning towards this approach since it's easier to use and doesn't require an extra CLI step to be run before setup-java. It has to be optional though.

Could you update README.md with some example of YAML of how this could be used

Ok, I've finished my updates.

You can see a successful run of this here: https://github.com/pied-piper-inc/fib-apache-maven/commit/0048dcb399de48db4bf184e7c1b1aa24f7eabeeb/checks?check_suite_id=333934912

I might add 1 additional note to the README about publishing to other registries.

Ok, as noted in the new docs https://github.com/clarkbw/setup-java/tree/maven-auth#apache-maven-within-a-shared-runner You can now specify an alternate location when using a shared runner but in your mvn deploy you need to specify the location of the settings file.

In the first pass at the docs I kept the .m2 directory but realized later it is confusing to tack that on when a user has specified a directory.

Updated the docs with suggestions from above, new examples seen here: https://github.com/clarkbw/setup-java/tree/maven-auth#apache-maven-with-a-settings-path

Looks good to me!. @chrispat could you take one more look before I merge the changes in. Also getting some extra 👀 from my team before merging in.

Ok, everything is updated again now.

The new code is using env variables in the settings.xml file. You can now have a very simple setup-java where you pass the $GITHUB_TOKEN to deploy and everything else works (assuming github is the ID you use in your pom.xml file).

    steps:
    - uses: actions/checkout@v1
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8

    - name: Build with Maven
      run: mvn -B package --file pom.xml

    - name: Publish to GitHub Packages Apache Maven
      run: mvn deploy
      env:
        GITHUB_TOKEN: ${{ github.token }} # GITHUB_TOKEN is the default env for the password

The new settings.xml file generated no longer contains passwords. We still need to allow people to configure the ID of the server as that corresponds to their pom.xml. The id defaults to github, username defaults to $GITHUB_ACTOR, and password defaults to $GITHUB_TOKEN.

<servers>
    <server>
      <id>github</id>
      <username>${env.GITHUB_ACTOR}</username>
      <password>${env.GITHUB_TOKEN}</password>
    </server>
</servers>

Each of these environment variable names are configurable. I did this so the default above can be very simple and when using an alternative like Maven people don't try to set the GITHUB_ACTOR env. Another option would have been to use something like $MAVEN_USER and $MAVEN_PASSWORD env variables that aren't configurable but that requires more env configuration in the simplest case. I'm happy to drop this if consensus is against the configuration.

I'm the person who posted about Github documentation problems on Hacker News a few hours ago. Thank you for your response.

I'll write more tomorrow, but what we really need is a complete, working example of a canonical Hello World Java/Maven app that can be built on Actions and deployed on Packages. I suggest creating a new Github project that does this. I should be able to fork it and run it in my own account without modification. You may want to create more than one such project to handle different situations.

Put copious notes right in the POM, settings, and .yml explaining exactly what is going on.

Mention this and similar projects (for npm, Gradle, etc.) prominently right in the written documentation. The docs can be a walkthrough of the sample app, with an explanation of what is going on and why.

Then provide reference docs. Have a doc that shows, in detail, what all of the options are in the action .yml. You also need a reference on all the environment variables that are available. I hadn't heard of GITHUB_ACTOR until I saw it above. Where is that documented?

Having app(s) like this will give us a place to post issues and bugs.

Be sure to read these:
https://stackoverflow.com/questions/59147676/error-code-400-when-trying-to-maven-deploy-to-github-packages-using-github-act
https://stackoverflow.com/questions/59313581/how-to-install-a-package-hosted-by-github-packages-with-github-actions?noredirect=1#comment105020411_59313581

Also, I suggest not putting settings.xml in the normal ~/.m2 dir. Put it in the root of the project, and then call "mvn --settings settings.xml deploy". That keeps everything in one place without the need to copy settings around.

If you find that getting the maven-deploy-plugin is too much of a pain, I suggest abandoning it and writing your own Maven plugin. A maven-github-packages plugin would avoid all of this configuration hell. All configuration could go right in the plugin config without the need for anything external. No settings.xml, no repositories, no distributionManagement.

Thanks @clarkbw for the hard work on this PR! Looks good to me so I'll be merging this into master. 🎉

I'll hold off till Monday after the code freeze (2nd) before merging this into releases/v1 and at that point anyone using actions/setup-java@v1 will be able to use this. I want to do some extra testing before getting the changes hit everyone.