[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462955#comment-15462955
]
Karl Heinz Marbaise edited comment on MNG-6083 at 9/4/16 1:49 PM:
------------------------------------------------------------------
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...
(BTW: [exec-maven-plugin can handle
toolchains|http://www.mojohaus.org/exec-maven-plugin/examples/example-exec-using-toolchains.html]
as well )
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
was (Author: khmarbaise):
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)
