[
https://issues.apache.org/jira/browse/MNG-6392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Z.M. Gao updated MNG-6392:
--------------------------------
Description:
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.
h2. Special fields in projects settings
{{servers.server[].configuration}} will be merged deeply, and prefer ones in
project settings.
Some fields should be controlled only by the user, not any project, so they are
always ignored and copied back from user or global level settings:
* localRepository
* interactiveMode
* offline
* usePluginRegistry
* proxies
*
servers.server[].\{username,password,privateKey,passphrase,filePermissions,directoryPermissions}
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.
was:
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.
> 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.
>
> h2. Special fields in projects settings
> {{servers.server[].configuration}} will be merged deeply, and prefer ones in
> project settings.
> Some fields should be controlled only by the user, not any project, so they
> are always ignored and copied back from user or global level settings:
> * localRepository
> * interactiveMode
> * offline
> * usePluginRegistry
> * proxies
> *
> servers.server[].\{username,password,privateKey,passphrase,filePermissions,directoryPermissions}
>
>
> 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)
