Karl Heinz Marbaise commented on MNG-6392:

Can you give a use case example for this? I think going a way to put a 
{{settings.xml}} into {{.mvn/settings.xml}} would run into the need to have a 
setup in every project which I don't like and based on the large organisations 
I have worked at it is bad cause you can't sync that correctly. Having a two 
possible location in particular {{$HOME/.m2/settings.xml}} in particular things 
like passwords/keys for access to repository managers etc. which I would like 
**NOT** to have inside the project (nor is this allowed in corporate 
Based on your suggestions via `./mvnw verify` after the code has been checked 
out can cause issues as well cause how should be downloaded the initial Maven 
for this? From where and by using which credentials for access to repositories 
which is very often limited by using credentials ? 

> 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