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

Reply via email to