[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15466136#comment-15466136 ] Robert Patrick commented on MNG-6083: - It seems that at least a few others have complained over the years about the lack of functionality for Maven toolchains. As such, I have written a custom toolchain and plugin to make toolchains work the way I hoped that they would. Assuming I don't hit any snags, I will eliminate .mvn/maven.config from my build and leverage the new "properties" toolchain type. In case you are interested, you can see what I have done at https://github.com/rpatrick00/properties-toolchain-plugin > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463231#comment-15463231
]
Robert Patrick commented on MNG-6083:
-
In playing with the paths toolchain, I see how I can specify a location for my
shell scripts with it (this eliminates one of about a dozen variables I need
for my system-test. However, I cannot figure out how to reference a variable
defined in a toolset to pass as an argument to my executable. I tried the
normal ${xxx} but that doesn't work. Without this, it seems that the only
option is a custom toolchain *and* a custom plugin to process it (e.g., a
plugin that reads the toolchain and adds properties to the build so that they
can referenced in the pom). While I am not afraid of writing plugins, I am
concerned that I am missing something obvious.
For example, how do I make this work when the xxxv1-home is defined in the
toolchain?
(quote)
org.codehaus.mojo
exec-maven-plugin
1.5.0
true
jcs-las-system-test
validate
exec
echoMessage.cmd
${xxxv1-home}
(quote)
> 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463097#comment-15463097 ] Robert Patrick commented on MNG-6083: - I understood how to set up the toolchain plugin and configure the exec plugin to use it. The issue with this page is that the details of what I need are omitted and replaced with "..." in the exec plugin declaration. How do I reference a tool path defined in the toolchain.xml in a exec plugin execution? For example, how do I fill in the element used in the argument to the shell script that the exec plugin execution calls? > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463087#comment-15463087 ] Karl Heinz Marbaise commented on MNG-6083: -- Just a short reply to exec-maven-plugin: You should check: http://www.mojohaus.org/exec-maven-plugin/examples/example-exec-using-toolchains.html ... > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463053#comment-15463053 ] Robert Patrick commented on MNG-6083: - >From my quick scan of the toolchains documentation, it will not help us. It >seems that the definitions in toolchain.xml are really only exposed to plugins >that leverage them. In our case, I need to invoke an external process (via >shell script) and pass it arguments to these environment-specific locations. >I don't see any documentation on how I can reference values defined in >toolchain.xml at any point in my POM. For example, here is a greatly >simplified example of a Maven exec plugin execution from the POM that doe the >pre-integration-test setup for each test execution:How would I reference those tools locations when they are defined in toolchain.xml? I didn't see anything in the docs that covered such a use case... > 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) org.codehaus.mojo exec-maven-plugin ... setup-environments-for-tests pre-integration-test exec ${bash-executable} ${system-test-bin}/setupTestEnvironment.sh ${software.location.v1} ${software.location.v2} ${software.location.v3} ${path-to-java7} ${path-to-java8} ${script-to-call}
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463010#comment-15463010 ] Robert Patrick commented on MNG-6083: - Karl, Comments (mostly) in order... 1.) I only have a profile for it so that I can chain them actions together: mvn clean install -Pdev,dev-install or mvn clean install -Pdev,system-test The dev profile is active by default so yes, it could be removed at the expense of needing to run mvn twice to run it with one of the other profiles. 2.) The dev-install profile runs our zipinstall and install-a2c-home modules--it does not include the core software modules built by the dev profile. 3.) system-test uses the failsafe plugin so yes, it runs during the standard integration-test-related phases... 4.) I am not sure how your suggestion to move the removal of functionality down into the module POMs really helps. It essentially just pushes the problem down a level at the expense of added complexity both in the POMs and for developers. 5.) Yes, we could move developer- and/or environment-specific information into settings.xml but that itself causes a problems. - Typically, I like to keep project dependencies out of settings.xml because we work across multiple projects where the information might be conflicting. I usually only define things that never change in my ~/.m2/settings.xml (e.g., mirrors, servers that require credentials and other such configuration). - When putting project-specific settings in settings.xml without which the project will not build, I *believe* that the best practice is to put settings.xml under source control, typically inside the project source tree. In doing so, I end up with a similar problem to the one that I currently have with maven.config. The only difference is that I can have as many settings-xxx.xml files in my source tree as I want--I just have to make sure that the developers (and IDEs) make sure to always add -s relative/path/ro/settings-rpatrick-laptop.xml to the mvn command-line. This is a pain because I, for one, get distracted sometimes and forget. 5.) I will take a look at toolchain.xml to see if this will help. 6.) Profiles for OSes don't help when the settings vary across environment. They also likely clash with our current use of profiles to segment the build. I could, for example, move system-test outside the main project into an integration-test project. The problem with that is the added complexity of figuring out how to retain control all of the dependency, plugin, etc. management in a single location. I have learned the hard way that parent POMs that are not the top-level aggregate POM for the project are problematic for things like the release plugin... I think your suggestions are glossing over the complexities of managing numerous Maven projects across a real-world development organization. At any point in time, I am working across a dozen or more projects and while you offer solutions like "push environment-specific settings into ~/.m2/settings.xml", you don't offer solutions for dealing with the complexities of managing multiple ~/.m2/settings.xml files that contain project-specific information (i.e., remembering to copy the right file to settings.xml and/or use remembering to use the right -s for each build). Clearly, maven.config was made for Maven command-line properties. This discussion seems to be about why Maven breaking compatibility between 3.3.3 and 3.3.9 is ok because what I am doing is wrong and I need to do things in the way you are suggesting so that I do not care about Maven breaking compatibility across releases. I wish my customers would accept this as an argument. Unfortunately, customers tend to use features in ways that you never expect and breaking compatibility for those features is a problem for customers. :-) Unfortunately, the way you are suggesting seems to introduce other problems that: - don't work well in real-world development environments where at any point in time, developers are working on any number of projects, and - most open-source projects using Maven (that I have looked at) avoid by not following some of your suggestions. Thanks, 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 c
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[
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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462956#comment-15462956
]
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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462892#comment-15462892 ] Robert Patrick commented on MNG-6083: - 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 build the software and runs the unit tests (using the default dev profile) and pushs 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
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462819#comment-15462819
]
Karl Heinz Marbaise commented on MNG-6083:
--
What do you mean by controlling sub modules by profile? You mean things like
this:
{code}
...
WhatEver
{code}
This is a bad idea...Where is the difference between your {{dev}},
{{dev-install}} ? Can you give real world examples where you build differs in
those things? Best would be to have a real example project which shows the
points you have?
Furthermore why are there differences between: {{fred-system-test}},
{{fred-linux-system-test}}, {{jane-system-test}} etc. ? What are the real
differences here? Tools ?
If so why not using {{mvn -pl ModuleYouWouldLikeToBuild}} plus dependent via
{{mvn -pl Moduly -amd}} ?
To make differences between OS you can simply use profiles like the following:
{code}
running-linux
linux
...
running-windows
windows
...
{code}
And why do you need differences between users ? It would be very helpful if you
can give real world examples how your build looks like (best would be an
example project on Github) so we have concrete things where we can discuss
about and may be i can see if i can help to improve your build or may be how we
might need to change Maven and or Plugins to support those scenarios...etc. ?
For defining tools you could use toolchains?
Unit tests are done by using maven-surefire-plugin and integration tests should
be done using maven-failsafe-plugin which is in a different life cycyle
phase...sometimes it makes sense to use a profile so you can turn on running
integration tests...
Running on Jenkins can automatically detected by a profile ?
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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459551#comment-15459551 ] Robert Patrick commented on MNG-6083: - Maven profiles would be one way of solving this. Of course, we are already using profiles to control what sub-modules get build in different situations (e.g.., dev, dev-install, system-test) so we cannot use profiles to handle this without losing the ability to control what submodules we run or at least not without duplicating tons of configuration across the various "environment-specific profiles": I would have to create multiple versions of our current system-test (i.e., integration tests) profile--one for every developer/environment--with all of the content duplicated (making for a pom maintenance nightmare) fred-system-test fred-linux-system-test jane-system-test mary-system-test bert-system-test jenkins-system-test Definitely not a manageable solution... It looks like the only solution Maven offers is environment variables. > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15459480#comment-15459480 ] Robert Patrick commented on MNG-6083: - And how exactly do you propose that would work if the property values vary across the environments where it needs to run (e.g., Windows vs. Linux)? You have made it very clear that you believe in checking the maven.config file into source control. What you haven't made clear is how you you handle environment-specific dependencies that the project has without the developers stepping on each other by overwriting maven.config every time they check in. Clearly, you don't feel like maven.config is the solution for this. So what is? > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15458725#comment-15458725
]
Karl Heinz Marbaise commented on MNG-6083:
--
And that's exactly the reason to checkin the {{.mvn/maven.config}} file with
your project
> 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15457205#comment-15457205 ] Robert Patrick commented on MNG-6083: - That's a great tip but given that I have a about 20 or so possible -Ds in maven.config, it will be very painful to do this on the command-line. I guess I will just stay on 3.3.3 until I invent my own way to deal with this outside of Maven...it's too bad whoever designed maven.config didn't consider this use case... > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15456728#comment-15456728 ] Pether Sörling commented on MNG-6083: - I can be wrong, but to be able to pass properties the the forked run in release:perform you can use -Darguments="-Dmyproperty=/u01/path/to/required/software". > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455269#comment-15455269 ] Robert Patrick commented on MNG-6083: - By the way, we are using them for Maven's command-line configuration... -Dmyproperty=/u01/path/to/required/software Or are you trying to tell me that it was only designed for -Ds that Maven defines? > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[ https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455263#comment-15455263 ] Robert Patrick commented on MNG-6083: - Well... In our case, we need to add things like "where is the database software installed" so that we can use the database client (e.g., sqlplus) to create/populate the necessary database tables that we need for our integration tests. This all works fine in Maven 3.3.3 so something that was changed in 3.3.9 changed the behavior. If I cannot use maven.config for environment-specific details, what do you suggest? Environment variables? System properties? I thought the whole idea of maven.config was to remove those undocumented project dependencies and make them part of the project. We have a maven.config-template file checked in. The developers copy that file and edit it for their environment. I suppose we could be more nazi-like and tell them that they all have to have everything in their environment in the specified location but, if you have ever worked with developers, that rubs them the wrong way... :-) > 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)
[jira] [Commented] (MNG-6083) Maven 3.3.9 breaks release:perform by not including maven.config
[
https://issues.apache.org/jira/browse/MNG-6083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453071#comment-15453071
]
Karl Heinz Marbaise commented on MNG-6083:
--
The {{.mvn/maven.config}} is only intended for Mavens command line
configuration and for nothing else and should be checked in. If this file
contains environment specific values it does not make sense. From the design
this file should not contain environment specific things. And of course if you
don't check it in into the version control the maven-release-plugin is not able
to check it out into the {{target/checkout}}.
> 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)
