maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Boué <gb...@apache.org>
Subject re: re-using server credentials for repositories
Date Wed, 20 Jul 2016 00:31:23 GMT
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://github.com/apache/maven/blob/maven-3.3.9/maven-core/src/main/java/org/apache/maven/internal/aether/DefaultRepositorySystemSessionFactory.java#L200
[2]: https://github.com/eclipse/aether-core/blob/aether-1.0.2.v20150114/aether-util/src/main/java/org/eclipse/aether/util/repository/DefaultAuthenticationSelector.java#L40
[3]: https://github.com/apache/maven/blob/maven-3.3.9/maven-core/src/main/java/org/apache/maven/bridge/MavenRepositorySystem.java#L246
[4]: https://github.com/eclipse/aether-core/blob/aether-1.0.2.v20150114/aether-util/src/main/java/org/eclipse/aether/util/repository/DefaultAuthenticationSelector.java#L52
[5]: https://github.com/apache/maven/commit/1068ab557c476a291f3f16bc2b2523d5613c5e17#diff-62baa3a3145d2df18244b7d719fc9686L42

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 -> http://example.com/url1
vs http://example.com/url2 @ 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://maven.apache.org/guides/mini/guide-multiple-repositories.html
[2] - http://stackjava-script.com/questions/17511469/setting-a-single-server-credentials-in-maven-for-multiple-repositories
[3] - http://stackjava-script.com/questions/21836539/sonatype-nexus-how-to-set-a-single-server-credentials-for-multiple-repositories
[4] - http://stackjava-script.com/questions/15011250/maven-meaning-of-repository-id
[5] - https://issues.apache.org/jira/browse/MNG-5585
 
 



 


Justin Georgeson


Release Management


 


Email: jgeorgeson@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.
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message