[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462955#comment-15462955 ]
Karl Heinz Marbaise commented on MNG-6083: ------------------------------------------ HI Robert, first thank you for the detailed explanations. {quote} dev - this is the default profile that developers use to build and run unit tests on the software we are building {quote} If this profile is the default than why do you need a profile for that? So this should result in calling Maven simply by {{mvn clean package}}. {quote}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.{quote} If I correctly understand this is a supplemental step which is {{dev}} plus {{dev-install}} so this will result in a profile yes which can be done: {{mvn clean patch -Pdev-install}} {quote}system-test - this profile is what runs our integration tests. These tests depend on complex setup for a commercial software package.{quote}In which life cycle phase do you run those integration test. I would assume pre-integration-test, integration-test and post-integration-test...So we have another profile...Ok...fine. {quote}release - this profile is the one used for running the Maven release process, which includes all modules.{quote} So as I mentioned before never remove modules from reactor better include/exclude the functionality within the module pom...If you like to run only a limited number of module simply use {{mvn -pl ... }}. So going to the point for the installation location you have mentioned. I would define install location via a property in the users {{settings.xml}} which is already user dependent...and check in your build via [maven-enforcer-plugin if the property exists|http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html]...and use it for installation... What you have mentioned about the {{system-test}} and the locations for JDK's and other tools is exactly the purpose of Maven Toolchains...You define a {{toolchains.xml}} in the users home folder (same location where settings.xml is located}} and define the location of JDK's and tools in there..Maven already supported to compile/run tests with the appropriate JDK's out of the box... For you point 3. There you can go the same way defining the properties in the settings.xml (users home folder) and on Jenkins you can define them also in the settings.xml of Jenkins (Config File Provider Plugins is best here). Also check via maven-enforcer-plugin if the needed properties do exist and fail if not... For your point 4: You can handle the differences between Linux / Unix by using a profile which is activated by different os name automatically which can be done also for exec-maven-plugin (May be we can/should improve [exec-maven-plugin|https://github.com/mojohaus/mojo-parent/issues])... So my conclusion here is: * Three explicit profiles which can be activated by developers or automatically by Jenkins depending what you like to do. * Defining things in settings.xml which are specific for the user (where is the installation folder or username/etc. for the database) * Using Toolchain make location of JDK's / Tools transparent... This means from my point of view no need for properties in {{.mvn/maven.config}} ? Do I miss something? Kind regards Karl Heinz Marbaise > 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)