Actually the way I see the Maven integration working is by decorating the environment-label mapping providers.

An environment-label mapper could take environment names like `maven-3.2.1`, `maven-3.0.4` and map them to tool installers for the corresponding version of Maven. This makes it easy to have a convention for Maven version without forcing people to name their tool installers following the convention.

When picking up such a mapping, it will actually inject a different PATH from that constructed by the ToolInstaller. On this different path will be a hook script that wraps `mvn` or `mvn.bat` such that the execution has an extra Maven extension that records the build operations that were executed and injects the settings configuration.

The hook script is required because somebody may well have a literate command along the lines of

MAVEN_OPTS=-Xmx512M mvn clean verify -P+extra-tests

So we cannot rely on injecting MAVEN_OPTS into the environment and hoping that the person writing the command knows how to not clobber us. Similarly we need to support somebody building with Maven and requiring their own extensions be registered

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to