maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Heinz Marbaise (JIRA)" <>
Subject [jira] [Issue Comment Deleted] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
Date Sun, 04 Sep 2016 13:44:20 GMT


Karl Heinz Marbaise updated MNG-6083:
    Comment: was deleted

(was: HI Robert, first thank you for the detailed explanations.

dev - this is the default profile that developers use to build and run unit tests on the software
we are building
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|]...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|])...

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

Kind regards
Karl Heinz Marbaise)

> Maven 3.3.9 breaks release:perform by not including maven.config
> ----------------------------------------------------------------
>                 Key: MNG-6083
>                 URL:
>             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

This message was sent by Atlassian JIRA

View raw message