[
https://issues.apache.org/jira/browse/MNG-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17392469#comment-17392469
]
Michael Osipov commented on MNG-7206:
-------------------------------------
Aha ok, nice idea.
Two notes:
1. I think we already have that hierarchy implicitly:
* Project is covered by {{jvm.config}}
* Installation is convered by {{/usr/local/etc/mavenrc}} and {{/etc/mavenrc}},
user by {{$HOME/.mavenrc}}. With this you can set a global {{MAVEN_OPTS}} and
override as user or extend with {{MAVEN_OPTS="...
$MAVEN_OPTS"}}/{{MAVEN_OPTS="$MAVEN_OPTS ..."}} or even use a manually set
{{MAVEN_OPTS}} with {{MAVEN_OPTS="... ${MAVEN_OPTS:-...}"}}
2. If I compare this with artifact repos I would consider (from lowest to
highest, highest overwrites): installation (like global {{settings.xml}}), user
{{like user {{settings.xml}}, project {like repos in POM).
What we can guarantee is {{java ... $project Launcher}}, but how the {{...}} is
poluated with {{MAVEN_OPTS}} is out of our control.
> Properly prioritize JVM options from MAVEN_OPTS and jvm.config
> --------------------------------------------------------------
>
> Key: MNG-7206
> URL: https://issues.apache.org/jira/browse/MNG-7206
> Project: Maven
> Issue Type: Task
> Components: Command Line
> Reporter: Michael Osipov
> Assignee: Michael Osipov
> Priority: Major
> Fix For: 4.0.x-candidate
>
>
> We currently have two ways of settings options with the JVM:
> 1. {{MAVEN_OPTS}}
> 2. {{.mvn/jvm.config}}
> We should correctly implement and document priority of those two.
> If we go from general to specific, a generic option shall be overridable (if
> possible) with a specific one. Thus, first {{MAVEN_OPTS}} is evaluted then
> {{jvm.config}} since the former applies to all executions while the latter
> applies to a specific project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
