Inherit Global Settings and User Settings

[nhojpatrick]

The -gs and -s command line flags are dropped by the child maven command(s) when spawned.

When using Jenkins and plugins like config-file-provider, the settings file is normally dynamically provided in a non standard location.

So this patch takes the global settings file and user settings file which the parent maven process is using, and explicitly passes these values to the spawned child processes.

It adds them to the start of the argLine, and if the argLine provides either -gs or -s then the argLine version is kept.

[nhojpatrick]

My IDE appeared to have auto formatted so have now revert that.

[aleksandr-m]

@nhojpatrick Setting it in argLine manually should work. Is this for "convenience" only? I am a bit wary of automagically adding stuff to argLine.

[nhojpatrick]

I've discovered several people I know alrady use this plugin and have to do similar workarounds in their views about bloating argLine.

So think of this in a corporate environment which has the CI/CD servers behind firewalls, you also have a corporate artifact repository. Your repo, say nexus requires authentication for both pull and push. Your using Jenkins and OpenShift, with new Jenkins slaves been dynamically created on demand for each job. Your Jenkins file extract might be;

    configFileProvider([configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS')]) {
        sh 'mvn -s $MAVEN_SETTINGS --batch-mode --no-transfer-progress --show-version -Pcicd gitflow:release -DskipTests -DargLine="-s $MAVEN_SETTINGS -Pcicd,release -DskipTests"'
    }

Maybe appending to the argLine magically is wrong, maybe separate variables should be introduced so it's crystal clear. If the global settings and user settings default to the locations the executing maven plugin is using, it shouldn't make things worse. If they want to use a different settings file or had already defined the settings file in argLine I don't override that.

[nhojpatrick]

I've done a slightly different version here #248.

[nhojpatrick]

Thinking about it I prefer the #248 version.

[stefanseifert]

i also prefer #248 over this approach

@nhojpatrick probably best to close this PR to cleanup the PR list a bit?