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

James Z.M. Gao commented on MNG-6392:
-------------------------------------

In my organizations, we share some common .mvn dirs, and synced via git 
sub\{module/tree/repo} commands. I agree the credentials should be always keep 
away from project source. So the .mvn/settings.xml should only contains the 
public or internal shared information, such as repo/mirror url for bootstrap 
the core extensions and parent poms, the http configurations of the server, 
such as timeout. In my cases, the _download_ action do not need auth in a 
internal network (out of this network, the project even can't be checked out), 
and we set .mvn/wrapper/maven-wrapper.properties to download Maven from a 
internal cache server. The important user/password/key for publish artifacts 
only exists on the CI/CD servers by releasing ops teams.

If the bootstrap repo/mirror also need auth, we indeed have to distribute 
credentials before first run `mvn verify`. But setup an identity is more light 
than merge a bunch of profiles/mirrors into .m2/settings.xml. Another pros is 
that the server credentials is composable from many different environments, 
they don't conflict; whereas if two project required different central mirrors, 
they can't be easily merged to fit both projects.

Here is an example for a developer who maintain three projects: private-app, 
company-app and open-source-lib, then

 
{code:java}
~/.m2/settings.xml -- holds the passwords for a company central mirror and a 
personal repo

/open-source-lib -- .mvn dir only contains the wrapper configuration

/company-app/.mvn/settings.xml -- contains a default activated profile with a 
central mirror only works in conpany

/private-app/.mvn/settings.xml -- contains a default activated profile with a 
private repository and a central mirror at home

{code}
 

 

In .mvn dir, the organization and the project ownner can define what maven 
features project needs and how maven integrates with the organization 
infrastructures;

In .m2 dir, the developer define who he is and how the maven cooperates with 
his local environment.

> Add Project Settings .mvn/settings.xml
> --------------------------------------
>
>                 Key: MNG-6392
>                 URL: https://issues.apache.org/jira/browse/MNG-6392
>             Project: Maven
>          Issue Type: New Feature
>          Components: Bootstrap & Build, Settings
>    Affects Versions: 3.5.3
>            Reporter: James Z.M. Gao
>            Priority: Major
>
> Maven originally have two settings slots, user and global. But the project 
> need and should have more ability to control how itself built by maven. Just 
> follow the core-extension way, we can add a new settings slot, project 
> settings at 
>  
> {code:java}
> ${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
>  
>  
> Then the settings merge order from high priority to low is
>  * project level
>  * user level
>  * global level
> This order is widely used in many projects such as git.
> In the project settings, we should always ignore some _personal local_ 
> fields, including localRepository, interactiveMode, offline and 
> usePluginRegistry.
>  
> With this feature, many things become easy. When we developing multiply 
> projects from different organizations/companies/envrionments, the maven 
> configurations may conflict, and are annoying to manage (edit manually or use 
> some switch scripts each time we switch the project or environment). Another 
> problem is when using some corp maven repositories or mirros for bootstraping 
> the team common root poms or core-extensions, the developers have to do some 
> setup actions. But the projects should be `mvn verify`-ed out of box.
>  
> Here is a [fast implementation via 
> core-extension|https://github.com/gzm55/project-settings-maven-extension], 
> but this feature should woks before loading extensions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to