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

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



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

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

Reply via email to