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
Description:
Need for support of multiple maven repositories.
Justification:
Custom (JFrog for example) Maven artifactories usually have separate repositories for release and snapshot versions.
Currently this action only supports one repository configuration, which makes it impossible to specify more than one (release and snapshot repositories for example).
That would inevitably lead to changing the maven config in the action yaml every time the version changes to/from release/snapshot.
If we had support for specifying multiple repositories, this problem will not happen at all.
With this support, we'll be able to generate settings.xml like this:
Extracted from PR #827: support configuring multiple Maven entries in generated settings.xml, each with its own id/username/password mapping, so release and snapshot repositories can be configured at the same time without editing workflow inputs between releases.
Core idea:
Extend setup-java Maven auth generation from a single server tuple to a list of server definitions.
Preserve existing single-server inputs for backward compatibility.
Add a structured way to provide multiple server credentials (and keep gpg.passphrase support).
Expected outcome:
settings.xml can contain multiple repository server entries in one run.
Workflows can publish release/snapshot artifacts without switching config.
This appears to be a duplicate of #85 ("Add support for multiple servers"). Both stem from the same limitation — setup-java currently supports configuring only a single Maven server entry in settings.xml — so configuring multiple repositories (e.g. separate release/snapshot or multiple registries) isn't possible.
This is being addressed by PR #1037, which adds a structured multi-server credentials input that generates multiple <server> entries in settings.xml. Tracking the work in #85 / #1037.
Closing as a duplicate of #85. Both issues request multiple Maven <server> credential entries in the generated settings.xml; the release/snapshot use case and structured-input requirements from this issue have been incorporated into #85. Repository URL and dependency-resolution configuration remains tracked separately in #1054.
Activity
v-aparnajyothi-y commentedon May 13, 2025
Hello @sudiptosarkar, Thank you for creating this issue and we will get back to you once we have some feedback on this :)
sudiptosarkar commentedon May 13, 2025
@aparnajyothi-y, Just so you know, I raised the PR for the same and linked in the issue description too. 🙂
gian1200 commentedon Jun 2, 2026
Hello., is there any update on this? It'd be a nice feature to have.
PS: the PR have some conflicts. It might need to be updated
brunoborges commentedon Jun 22, 2026
Extracted from PR #827: support configuring multiple Maven entries in generated settings.xml, each with its own id/username/password mapping, so release and snapshot repositories can be configured at the same time without editing workflow inputs between releases.
Core idea:
Expected outcome:
Reference: PR #827
brunoborges commentedon Jun 22, 2026
This appears to be a duplicate of #85 ("Add support for multiple servers"). Both stem from the same limitation —
setup-javacurrently supports configuring only a single Maven server entry insettings.xml— so configuring multiple repositories (e.g. separate release/snapshot or multiple registries) isn't possible.This is being addressed by PR #1037, which adds a structured multi-server credentials input that generates multiple
<server>entries insettings.xml. Tracking the work in #85 / #1037.brunoborges commentedon Jul 28, 2026
Closing as a duplicate of #85. Both issues request multiple Maven
<server>credential entries in the generatedsettings.xml; the release/snapshot use case and structured-input requirements from this issue have been incorporated into #85. Repository URL and dependency-resolution configuration remains tracked separately in #1054.