[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462892#comment-15462892
]
Robert Patrick edited comment on MNG-6083 at 9/4/16 1:07 PM:
-------------------------------------------------------------
Karl,
I already explained why I need different environments for different developers.
We are building real-world software that depends on commercial software
packages. I have four profiles defined in my top-level POM:
dev - this is the default profile that developers use to build and run unit
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file,
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests. These tests
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process,
that includes all modules.
We have two main Jenkins job types. One builds the software and runs the unit
tests (using the default dev profile) and pushes the resulting SNAPSHOT JARs
into Artifactory. The other job runs nightly and runs our system-test profile
to build our installer and run the integration tests against it, publishing the
new installer to Artifactory if the integration tests succeed. This installer
can then be picked up by automated QA jobs that further test the quality of the
nightly build.
Our developers can also run the integration tests locally prior to checking in,
if they choose. I encourage this on large changes since I "fine" them every
time they break a Jenkins nightly build job.
The current properties in maven.config are:
1.) The location of the "install directory" where the dev-install profile
creates an installed version of the software. For example, mine is currently
set to -Da2c-home-parent-dir=c:\tmp on my laptop. When running on my devops
environment based on Linux, I cannot use c:\tmp. My other developers use there
own locations.
2.) Our "system-test" module that runs the integration tests for the software
we are building depends on a large commercial software package and runs our
tests against 3 different versions of that package, requiring 2 different
versions of java (depending on which version a particular test uses). The
other commercial software package is the Oracle database. As such, the
maven.config file current has the locations where the three versions of the
commercial software package and 2 different JDK versions are installed.
3.) The integration tests also depend on an Oracle database, where some
developers use an installation on their laptop but Jenkins (and my release
process) use a centrally installed database. In order to make sure that
developers (and Jenkins) don't step on one another when they happen to run
integration tests concurrently, the maven.config file contains the database
connection information required by the test (e.g., connection URL, user name,
and password).
4.) To make the integration tests work on both Windows and Linux, we ended up
writing shell scripts that do the pre-integration-test setup and
post-integration-test teardown of the environments required to run the
commercial software package mentioned in step 2. As such, the maven.config
file also contains a property that tells the maven exec plugin executions the
shell-script-extension to use for this particular build (i.e., cmd or sh).
What I was trying to say about the fred-system-test profile, etc. was that
trying to push the environment-specific settings currently in maven.config into
the profiles would mean that I would need to copy the existing profiles
multiple times, one for each environment. I see that as a non-starter. I am
not familiar enough with toolchains to know whether this would help me or not.
My current thinking is that if I cannot use maven.config for these
environment-specific configuration, I will be forced to drop back to
environment variables--even though I see this as a more error-prone mechanism.
Is this real enough for you? I am happy to show you all the detail but my
employer might get upset if I posted the actual POMs and such to such a public
forum...
Hope this helps,
Robert
was (Author: rhpatrick00):
Karl,
I already explained why I need different environments for different developers.
We are building real-world software that depends on commercial software
packages. I have four profiles defined in my top-level POM:
dev - this is the default profile that developers use to build and run unit
tests on the software we are building
dev-install - this profile that builds our "installer", which is a zip file,
and "installs" it in a directory that developers can use to run manual tests.
system-test - this profile is what runs our integration tests. These tests
depend on complex setup for a commercial software package.
release - this profile is the one used for running the Maven release process,
that includes all modules.
We have two main Jenkins job types. One builds the software and runs the unit
tests (using the default dev profile) and pushes the resulting SNAPSHOT JARs
into Artifactory. The other job runs nightly and runs our system-test profile
to build our installer and run the integration tests against it, publishing the
new installer to Artifactory if the integration tests succeed. This installer
can then be picked up by automated QA jobs that further test the quality of the
nightly build.
The current properties in maven.config are:
1.) The location of the "install directory" where the dev-install profile
creates an installed version of the software. For example, mine is currently
set to -Da2c-home-parent-dir=c:\tmp on my laptop. When running on my devops
environment based on Linux, I cannot use c:\tmp. My other developers use there
own locations.
2.) Our "system-test" module that runs the integration tests for the software
we are building depends on a large commercial software package and runs our
tests against 3 different versions of that package, requiring 2 different
versions of java (depending on which version a particular test uses). The
other commercial software package is the Oracle database. As such, the
maven.config file current has the locations where the three versions of the
commercial software package and 2 different JDK versions are installed.
3.) The integration tests also depend on an Oracle database, where some
developers use an installation on their laptop but Jenkins (and my release
process) use a centrally installed database. In order to make sure that
developers (and Jenkins) don't step on one another when they happen to run
integration tests concurrently, the maven.config file contains the database
connection information required by the test (e.g., connection URL, user name,
and password).
4.) To make the integration tests work on both Windows and Linux, we ended up
writing shell scripts that do the pre-integration-test setup and
post-integration-test teardown of the environments required to run the
commercial software package mentioned in step 2. As such, the maven.config
file also contains a property that tells the maven exec plugin executions the
shell-script-extension to use for this particular build (i.e., cmd or sh).
What I was trying to say about the fred-system-test profile, etc. was that
trying to push the environment-specific settings currently in maven.config into
the profiles would mean that I would need to copy the existing profiles
multiple times, one for each environment. I see that as a non-starter. I am
not familiar enough with toolchains to know whether this would help me or not.
My current thinking is that if I cannot use maven.config for these
environment-specific configuration, I will be forced to drop back to
environment variables--even though I see this as a more error-prone mechanism.
Is this real enough for you? I am happy to show you all the detail but my
employer might get upset if I posted the actual POMs and such to such a public
forum...
Hope this helps,
Robert
> 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)
