[ 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)