Provide an option to by pass generating a settings.xml file

When using self-hosted runners we provision compute with a Maven settings.xml and currently this action will overwrite our correct settings.xml with one that’s inoperable. It would be nice to signal to the action to not generate a settings.xml file.

Another option might be to allow a template .github/workflow/maven/settings.xml that can be provisioned on the runner. In the case of running with GitHub actions proper the template can use ${{ secrets.references }} and in self-host just normal envars which Maven will interpolate into the settings file. Either way it’s secure.

[anderius]

I am still at loss as to why the action deals with Maven at all. Why should installing java involve anything with Maven?

[maxim-lobanov]

I don’t have much historical context but @konradpabjan has shared some details in https://github.com/actions/setup-java/pull/132#issuecomment-796873588

The main reason why setup-java has Maven functionality in it is so that it’s easier to publish to GitHub package registry. When the initial maven publishing feature was added there was a pretty lengthy debate (and I was very much against adding the functionality to setup-java) but we ultimately decided to do it so that publishing would “just work” without any extra configurations or any other actions. I agree that it somewhat distorts the single purpose intent that setup-java initially was meant to provide (and that most users think it provides) but we ultimately decided that the pros outweight the cons. One solution that was floating around was to create a separate setup-maven or setup-gradle package but we don’t have the bandwidth to support yet another action and the maintenance burden would also be very high so we just extended setup-java Before we started work on the v2-preview, we had some discussions regarding what to do with the existing Maven publishing functionality and the general consensus was to just leave it as is. Don’t prioritize any new features for it, don’t break what we currently have, but keep the current functionality as is because we still want publishing to GitHub packages to “just work”.