Thank you for the decisive answer on the current implementation. I definitely think making the mapping more automatic based on matching a pattern to the URL and/or specifying authentication realm for which the credentials apply is the best solution. That seems (to me) the most intuitive.
I'll start voting/commenting on related JIRA tickets. > -----Original Message----- > From: guillaume_b...@orange.fr [mailto:guillaume_b...@orange.fr] On > Behalf Of Guillaume Boué > Sent: Tuesday, July 19, 2016 7:31 PM > To: Maven Users List <users@maven.apache.org> > Subject: [EXTERNAL] re: re-using server credentials for repositories > > Hi, > > Looking at the code, there is really a one-to-one implicit mapping between the > repository id and the server id used to look-up authentication information. > > Maven adds to a DefaultAuthenticationSelector the server id [1] as key of a > map Id -> authentication info [2]. Then, a possible authentication info is > retrieved for a repository by asking it to the AuthenticationSelector for a > given > repo [3], and this method internally fetches it from the repository id [4]. > > > > I didn't test with all Maven versions but with Maven 3, I'd expect an error. I > tracked this commit [5] where you can see that the warning was changed to an > error for Maven 3.0-alpha5. > > > > Perhaps it would be possible to add an element "serverId" inside "repository"? > Without it, default to the repository id as before and, with it, use it as > the key to > search for the authentication info. I don't know about a possible road-map for > this feature (or for MNG-5585). > > > > [1]: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com_apache_maven_blob_maven-2D3.3.9_maven- > 2Dcore_src_main_java_org_apache_maven_internal_aether_DefaultRepositor > ySystemSessionFactory.java-23L200&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=XOQr > IG06vlPdi5Jhpu760B-ngiTlNdR_0ObF1fPN12I&e= > [2]: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com_eclipse_aether-2Dcore_blob_aether- > 2D1.0.2.v20150114_aether- > 2Dutil_src_main_java_org_eclipse_aether_util_repository_DefaultAuthenticati > onSelector.java-23L40&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=RZRr- > q_qRCC2RdCYeuKVTG1BAwKeZRf9o3t1IHCHI0w&e= > [3]: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com_apache_maven_blob_maven-2D3.3.9_maven- > 2Dcore_src_main_java_org_apache_maven_bridge_MavenRepositorySystem.j > ava-23L246&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=dvV7 > E6mQaTeMWRdJGuay6rltjw8KXYBNgwDWt7U2NXk&e= > [4]: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com_eclipse_aether-2Dcore_blob_aether- > 2D1.0.2.v20150114_aether- > 2Dutil_src_main_java_org_eclipse_aether_util_repository_DefaultAuthenticati > onSelector.java-23L52&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=I_M3 > AFPTjkRHoDOEKTe13MTWPfEy573zQVQ2QDO1A00&e= > [5]: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__github.com_apache_maven_commit_1068ab557c476a291f3f16bc2b2523d > 5613c5e17-23diff- > 2D62baa3a3145d2df18244b7d719fc9686L42&d=CwIFaQ&c=PskvixtEUDK7wuW > U- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=8- > vVUeqE0X9Nl8y3W1-CJEMBLhrVt0IeuDGpt7dc3us&e= > > Regard, > Guillaume > > > > > Message du 19/07/16 23:57 > > De : "Justin Georgeson" > > A : "Maven Users List" > > Copie à : > > Objet : re-using server credentials for repositories > > > > > I’m curious why there doesn’t seem to be a way to reuse server credentials > across multiple repositories (at least without a warning for those fortunate > few > on stack-java-script who claim success). For reference I mean as exemplified > in > [1], I have to define in my settings.xml a unique settings.servers.server for > each > projects.repositories.repository in my pom.xml, even if the credentials are > the > same. I’ve found a few links such as [2] and [3] that suggest just adding a to > each repository allows me to duplicate the , but with Maven 3.2.5 and 3.3.9 I > get a failure > > [ERROR] 'repositories.repository.id' must be unique: artifactory-lmk -> > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__example.com_url1&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=- > YjpFUijn4nV2QT5gxCWcjs12wOX9s5ycrKteMFxB7g&e= vs > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__example.com_url2&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=sUPK > 8zyzVLEglJOKAQtgi4pzQxaCpYNY0v9mFxjN778&e= @ line 26, column 13 > > There’s also [4] which says that nope, unique ID is required. Link [2] is the > newest and Manfred says it works, and that’s the accepted answer there. Does > it only work for distributionManagement.repositories and not for > build.repositories? Is there anything on the roadmap to address this in near- > future release? There’s MNG-5585 [5] which would side-step the issue by > presumably letting the HTTP wagon match the correct credentials > automatically by authentication realm, without the user having to map them > out explicitly. That’d be nice. > > [1] - https://urldefense.proofpoint.com/v2/url?u=https- > 3A__maven.apache.org_guides_mini_guide-2Dmultiple- > 2Drepositories.html&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=y5Xb- > ECdx1wv0twXkenbjq96oNYK_KEs3wo3cSq7wj4&e= > [2] - https://urldefense.proofpoint.com/v2/url?u=http-3A__stackjava- > 2Dscript.com_questions_17511469_setting-2Da-2Dsingle-2Dserver- > 2Dcredentials-2Din-2Dmaven-2Dfor-2Dmultiple- > 2Drepositories&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=Bcvz > wEgIt8A2H_aQyrJDcczaurvVcaZjMXcBeTgbTQY&e= > [3] - https://urldefense.proofpoint.com/v2/url?u=http-3A__stackjava- > 2Dscript.com_questions_21836539_sonatype-2Dnexus-2Dhow-2Dto-2Dset-2Da- > 2Dsingle-2Dserver-2Dcredentials-2Dfor-2Dmultiple- > 2Drepositories&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=VfRp > anO7QCcQpm9AfPUwPAr1BmG695ZlbzC48vlYe2Y&e= > [4] - https://urldefense.proofpoint.com/v2/url?u=http-3A__stackjava- > 2Dscript.com_questions_15011250_maven-2Dmeaning-2Dof-2Drepository- > 2Did&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=DLb0 > Q1ubUb-nwH4aOufrRHoofpez4lEwOYFSNfzZuVM&e= > [5] - https://urldefense.proofpoint.com/v2/url?u=https- > 3A__issues.apache.org_jira_browse_MNG- > 2D5585&d=CwIFaQ&c=PskvixtEUDK7wuWU- > tIg6oKuGYBRbrMXk2FZvF0UfTo&r=dLxYM3PBhAqFnkH7uKz_OVZL1uyui4QoEm > BCjCmEiTk&m=kxV_OBrfrqA3HJvQpLbw6RBzFx4wh2DAkwYYUa2HVbk&s=ofuBz > 50TXYDNdJhF_A3l6rIFkOTWNg7f5F9VrKpdkSU&e= > > > > > > > > > Justin Georgeson > > > Release Management > > > > > > Email: jgeorge...@lgc.com > > > Office: +1 713-839-3010 > > Fax: +1 713-839-2285 > > > > > > > > > > Follow Halliburton: LinkedIn | Facebook | Twitter | YouTube | Blog > > > > > > > > > > > > > > > > > > > This e-mail, including any attached files, may contain confidential and > privileged information for the sole use of the intended recipient. Any review, > use, distribution, or disclosure by others is strictly prohibited. If you are > not the > intended recipient (or authorized to receive information for the intended > recipient), please contact the sender by reply e-mail and delete all copies of > this message. > >
