[ 
https://issues.apache.org/jira/browse/SCM-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17963309#comment-17963309
 ] 

ASF GitHub Bot commented on SCM-826:
------------------------------------

jira-importer commented on issue #1055:
URL: https://github.com/apache/maven-scm/issues/1055#issuecomment-2964643101

   
**[phansson](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=phansson)**
 commented
   
   I now realize that the folks over at 
[maven-release-plugin](http://maven.apache.org/maven-release/maven-release-plugin/)
 have come up with a much better solution for this. They've introduced a 
special property, `project.scm.id`, which you can set to point to the id of the 
server (from settings.xml) that you want to use.
   
   In other words in your POM you would have:
   
   ```xml
   <properties>
     <project.scm.id>my-scm-server<project.scm.id>
   </properties>
   ```
   
   And the following in your settings.xml file:
   
   ```xml
   <settings>  
      <servers>  
         <server>
            <id>my-scm-server</id>  
            <username>myUser</username>  
            <password>myPassword</password>  
         </server>   
      </servers>
   </settings>
   ```
   
   I believe that is an excellent solution. It is indeed much better than my 
solution above. The only bewildering thing about this solution is why it was 
implemented in the maven-release-plugin and not in the SCM API. Oh well. Since 
I do not currently use the SCM API or SCM Plugin directly the solution from 
maven-release-plugin fits my needs.
   
   Note: This new feature was introduced in version 2.3 of the 
maven-release-plugin. Be careful if you are using for example Maven 3.0.5 since 
that version by default uses version 2.0 of the maven-release-plugin and that 
is just too old. Make sure to force to a later version of the 
maven-release-plugin if you want to use this feature.
   




> Allow multiple identities on same SCM host
> ------------------------------------------
>
>                 Key: SCM-826
>                 URL: https://issues.apache.org/jira/browse/SCM-826
>             Project: Maven SCM (Moved to GitHub Issues)
>          Issue Type: Improvement
>          Components: maven-plugin
>            Reporter: phansson
>            Priority: Major
>
> It is no longer uncommon for a developer to have several identities on a 
> single SCM host (just think of sites such as GitHub and BitBucket).
> The current scheme for centralizing credentials is to put them in 
> settings.xml and then Maven SCM Plugin will match the host name in {{<scm>}} 
> section of the POM with the {{<id>}} section from {{<server>}} in 
> settings.xml.
> As far as I know (pretty much undocumented) this scheme will currently only 
> work for a single identity at the VCS host.
> My proposal is to expand on the current scheme so that it will allow some 
> form of *longest match* which would include a potential prefixed username in 
> the SCM URL  (e.g. [email protected]) or matching on the URL path 
> (github.com/apache rather than just matching on the hostname itself).
> Here's an example of how I envisage it:
> {code:xml}
> <settings>
>   <servers>
>     <!-- Would match any GitHub URL with user1 prefixed in URL -->
>     <server>
>       <id>[email protected]</id>
>       <username>user1</username>
>       <password>mysecret</password>
>     </server>
>     <!-- Would match any GitHub URL with user2 prefixed in URL -->
>     <server>
>       <id>[email protected]</id>
>       <username>user2</username>
>       <password>mysecret</password>
>     </server>
>     <!-- Would match URLs from host github.com where path 
>            is 'apache' and also user2 is prefixed in URL -->
>     <server>
>       <id>[email protected]/apache</id>
>       <username>user2</username>
>       <password>mysecret</password>
>     </server>
>     <!-- default -->
>     <server>
>       <id>github.com</id>
>       <username>user1</username>
>       <password>mysecret</password>
>     </server>
> {code}
> This enhancement would be completely backwards compatible, is simple to 
> implement and will solve a lot of use cases in one go.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to