[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459551#comment-15459551
]
Robert Patrick edited comment on MNG-6083 at 9/2/16 8:50 PM:
-------------------------------------------------------------
Maven profiles would be one way of solving this. Of course, we are already
using profiles to control what sub-modules get build in different situations
(e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this
without losing the ability to control what submodules we run or at least not
without duplicating tons of configuration across the various
"environment-specific profiles":
I would have to create multiple versions of our current system-test (i.e.,
integration tests) profile, one for every developer/environment, with all of
the content duplicated (making for a pom maintenance nightmare)
fred-system-test
fred-linux-system-test
jane-system-test
mary-system-test
bert-system-test
jenkins-system-test
Definitely not a manageable solution... It looks like the only solution Maven
offers is environment variables.
The concern is whether those will work properly with the Maven release process
or not...
was (Author: rhpatrick00):
Maven profiles would be one way of solving this. Of course, we are already
using profiles to control what sub-modules get build in different situations
(e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this
without losing the ability to control what submodules we run or at least not
without duplicating tons of configuration across the various
"environment-specific profiles":
I would have to create multiple versions of our current system-test (i.e.,
integration tests) profile, one for every developer/environment, with all of
the content duplicated (making for a pom maintenance nightmare)
fred-system-test
fred-linux-system-test
jane-system-test
mary-system-test
bert-system-test
jenkins-system-test
Definitely not a manageable solution... It looks like the only solution Maven
offers is environment variables.
> Maven 3.3.9 breaks release:perform by not including maven.config
> ----------------------------------------------------------------
>
> Key: MNG-6083
> URL: https://issues.apache.org/jira/browse/MNG-6083
> Project: Maven
> Issue Type: Bug
> Components: General
> Affects Versions: 3.3.9
> Reporter: Robert Patrick
> Priority: Blocker
>
> Our release process runs both our build and our integration tests. The
> integration tests rely on our project root directory's .mvn/maven.config file
> to run properly. The maven.config file is NOT checked into the source tree
> because it contains environment-specific values so each developer has their
> own version of it on each machine on which they build.
> This has been working fine for months now but simply changing the version of
> Maven used from 3.3.3 to 3.3.9 causes the build to break due to not having
> the -Ds defined in $PROJECT_ROOT/.mvn/maven.config.
> It appears that the release:perform goal checks out the release source in
> another location and with Maven 3.3.9, the maven.config from the original
> location is not being used. The build specifies the release-plugin version
> so the difference seems to be in the core Maven distribution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
