Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@maven.apache.org
Date: Sun, 4 Sep 2016 13:44:20 +0000 (UTC)
From: "Karl Heinz Marbaise (JIRA)" <jira@apache.org>
To: issues@maven.apache.org
Message-ID: <JIRA.13000704.1472322122000.488417.1472996660608@Atlassian.JIRA>
In-Reply-To: <JIRA.13000704.1472322122000@Atlassian.JIRA>
References: <JIRA.13000704.1472322122000@Atlassian.JIRA> <JIRA.13000704.1472322122336@arcas>
Subject: [jira] [Issue Comment Deleted] (MNG-6083) Maven 3.3.9 breaks
 release:perform by not including maven.config
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sun, 04 Sep 2016 13:44:22 -0000


     [ https://issues.apache.org/jira/browse/MNG-6083?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

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

(was: 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 z=
ip file, and "installs" it in a directory that developers can use to run ma=
nual tests.{quote}=20
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 pr=
e-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/e=
xclude 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 w=
ould define install location via a property in the users {{settings.xml}} w=
hich is already user dependent...and check in your build via [maven-enforce=
r-plugin if the property exists|http://maven.apache.org/enforcer/enforcer-r=
ules/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}}=C2=A0in the users home folder (same location where set=
tings.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 ou=
t of the box...

For you point 3. There you can go the same way defining the properties in t=
he 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 an=
d fail if not...

For your point 4: You can handle the differences between Linux / Unix by us=
ing a profile which is activated by different os name automatically which c=
an be done also for exec-maven-plugin (May be we can/should improve [exec-m=
aven-plugin|https://github.com/mojohaus/mojo-parent/issues])...

So my conclusion here is:
 * Three explicit profiles which can be activated by developers or automati=
cally by Jenkins depending what you like to do.
 * Defining things in settings.xml which are specific for the user (where i=
s 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.con=
fig}} ? 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 i=
ntegration tests rely on our project root directory's .mvn/maven.config fil=
e to run properly.  The maven.config file is NOT checked into the source tr=
ee because it contains environment-specific values so each developer has th=
eir 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 hav=
ing 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)