[jira] [Comment Edited] (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=15463231#comment-15463231
]
Robert Patrick edited comment on MNG-6083 at 9/4/16 5:32 PM:
-
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?
org.codehaus.mojo
exec-maven-plugin
1.5.0
true
jcs-las-system-test
validate
exec
echoMessage.cmd
${xxxv1-home}
was (Author: rhpatrick00):
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?
org.codehaus.mojo
exec-maven-plugin
1.5.0
true
jcs-las-system-test
validate
exec
echoMessage.cmd
${xxxv1-home}
> 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] [Comment Edited] (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=15463231#comment-15463231
]
Robert Patrick edited comment on MNG-6083 at 9/4/16 5:31 PM:
-
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?
org.codehaus.mojo
exec-maven-plugin
1.5.0
true
jcs-las-system-test
validate
exec
echoMessage.cmd
${xxxv1-home}
was (Author: rhpatrick00):
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=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-5878) add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
[
https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15463126#comment-15463126
]
Hudson commented on MNG-5878:
-
FAILURE: Integrated in Jenkins build maven-3.x #1368 (See
[https://builds.apache.org/job/maven-3.x/1368/])
MNG-5878 improved explanations (hboutemy: rev
7846f081a696baa6c88b0420b684829fb97e1d4d)
* (edit) maven-model-builder/src/site/apt/index.apt
> add support for module name != artifactId in every calculated URLs (project,
> SCM, site): special project.directory property
> ---
>
> Key: MNG-5878
> URL: https://issues.apache.org/jira/browse/MNG-5878
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Hervé Boutemy
> Fix For: 3.4.0
>
>
> Say you have this project structure:
> {noformat}
> /
> |-- module1
> |-- module2
> {noformat}
> and artifactIds are named:
> {noformat}
> my-parent
> |-- my-module1
> |-- my-module2
> {noformat}
> Prefix {{my-}} is omitted for brevity in module names. For instance, Jersey
> does that.
> When the SCM report is built, the artifactId is always used for path
> composition which leads to incorrect URLs. You can of course set the
> parameter {{checkoutDirectoryName}} but this would be extremely tedious for
> all modules down the tree.
> The code should obtain the module name and use it for URL composition.
--
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=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=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] [Comment Edited] (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=15463053#comment-15463053
]
Robert Patrick edited comment on MNG-6083 at 9/4/16 3:13 PM:
-
>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:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
idsetup-environments-for-tests/id
phasepre-integration-test/phase
goals
goalexec/goal
/goals
configuration
executable${bash-executable}/executable
arguments
shell-script${system-test-bin}/setupTestEnvironment.sh/shell-script
path_to_commercial_software_v1${software.location.v1}/path_to_commercial_software_v1
path_to_commercial_software_v2${software.location.v2}/path_to_commercial_software_v2
path_to_commercial_software_v3${software.location.v3}/path_to_commercial_software_v3
path_to_jdk7${path-to-java7}/path_to_jdk7
path_to_jdk8${path-to-java8}/path_to_jdk8
script_to_call_value${script-to-call}/script_to_call_value
/arguments
/configuration
/execution
...
/executions
/plugin
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...
was (Author: rhpatrick00):
>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:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
idsetup-environments-for-tests/id
phasepre-integration-test/phase
goals
goalexec/goal
/goals
configuration
executable${bash-executable}/executable
arguments
shell-script${system-test-bin}/setupTestEnvironment.sh/shell-script
path_to_commercial_software_v1${software.location.v1}/path_to_commercial_software_v1
path_to_commercial_software_v2${software.location.v2}/path_to_commercial_software_v2
path_to_commercial_software_v3${software.location.v3}/path_to_commercial_software_v3
path_to_jdk7${path-to-java7}/path_to_jdk7
path_to_jdk8${path-to-java8}/path_to_jdk8
script_to_call_value${script-to-call}/script_to_call_value
/arguments
/configuration
/execution
...
/executions
/plugin
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)
[jira] [Updated] (MNG-5878) add support for module name != artifactId in every calculated URLs (project, SCM, site): special project.directory property
[
https://issues.apache.org/jira/browse/MNG-5878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNG-5878:
---
Summary: add support for module name != artifactId in every calculated URLs
(project, SCM, site): special project.directory property (was: add support for
module name != artifactId in every calculated URLs (SCM, site): special
project.directory property)
> add support for module name != artifactId in every calculated URLs (project,
> SCM, site): special project.directory property
> ---
>
> Key: MNG-5878
> URL: https://issues.apache.org/jira/browse/MNG-5878
> Project: Maven
> Issue Type: New Feature
> Components: Inheritance and Interpolation
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Hervé Boutemy
> Fix For: 3.4.0
>
>
> Say you have this project structure:
> {noformat}
> /
> |-- module1
> |-- module2
> {noformat}
> and artifactIds are named:
> {noformat}
> my-parent
> |-- my-module1
> |-- my-module2
> {noformat}
> Prefix {{my-}} is omitted for brevity in module names. For instance, Jersey
> does that.
> When the SCM report is built, the artifactId is always used for path
> composition which leads to incorrect URLs. You can of course set the
> parameter {{checkoutDirectoryName}} but this would be extremely tedious for
> all modules down the tree.
> The code should obtain the module name and use it for URL composition.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (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=15463053#comment-15463053
]
Robert Patrick edited comment on MNG-6083 at 9/4/16 3:08 PM:
-
>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:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
idsetup-environments-for-tests/id
phasepre-integration-test/phase
goals
goalexec/goal
/goals
configuration
executable${bash-executable}/executable
arguments
shell-script${system-test-bin}/setupTestEnvironment.sh/shell-script
path_to_commercial_software_v1${software.location.v1}/path_to_commercial_software_v1
path_to_commercial_software_v2${software.location.v2}/path_to_commercial_software_v2
path_to_commercial_software_v3${software.location.v3}/path_to_commercial_software_v3
path_to_jdk7${path-to-java7}/path_to_jdk7
path_to_jdk8${path-to-java8}/path_to_jdk8
script_to_call_value${script-to-call}/script_to_call_value
/arguments
/configuration
/execution
...
/executions
/plugin
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...
was (Author: rhpatrick00):
>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:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
idsetup-environments-for-tests/id
phasepre-integration-test/phase
goals
goalexec/goal
/goals
configuration
executable${bash-executable}/executable
arguments
shell-script${system-test-bin}/setupTestEnvironment.sh/shell-script
path_to_commercial_software_v1${software.location.v1}/path_to_commercial_software_v1
path_to_commercial_software_v2${software.location.v2}/path_to_commercial_software_v2
path_to_commercial_software_v3${software.location.v3}/path_to_commercial_software_v3
path_to_jdk7${path-to-java7}/path_to_jdk7
path_to_jdk8${path-to-java8}/path_to_jdk8
script_to_call_value${script-to-call}/script_to_call_value
/arguments
/configuration
/execution
...
/executions
/plugin
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
[jira] [Comment Edited] (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=15463053#comment-15463053
]
Robert Patrick edited comment on MNG-6083 at 9/4/16 3:07 PM:
-
>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:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
idsetup-environments-for-tests/id
phasepre-integration-test/phase
goals
goalexec/goal
/goals
configuration
executable${bash-executable}/executable
arguments
shell-script${system-test-bin}/setupTestEnvironment.sh/shell-script
path_to_commercial_software_v1${software.location.v1}/path_to_commercial_software_v1
path_to_commercial_software_v2${software.location.v2}/path_to_commercial_software_v2
path_to_commercial_software_v3${software.location.v3}/path_to_commercial_software_v3
path_to_jdk7${path-to-java7}/path_to_jdk7
path_to_jdk8${path-to-java8}/path_to_jdk8
script_to_call_value${script-to-call}/script_to_call_value
/arguments
/configuration
/execution
...
/executions
/plugin
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...
was (Author: rhpatrick00):
>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:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
idsetup-environments-for-tests/id
phasepre-integration-test/phase
goals
goalexec/goal
/goals
configuration
executable${bash-executable}/executable
arguments
shell-script${system-test-bin}/setupTestEnvironment.sh/shell-script
path_to_commercial_software_v1${software.location.v1}/path_to_commercial_software_v1
path_to_commercial_software_v2${software.location.v2}/path_to_commercial_software_v2
path_to_commercial_software_v3${software.location.v3}/path_to_commercial_software_v3
path_to_jdk7${path-to-java7}/path_to_jdk7
path_to_jdk8${path-to-java8}/path_to_jdk8
script_to_call_value${script-to-call}/script_to_call_value
/arguments
/configuration
/execution
...
/executions
/plugin
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
[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=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:
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdexec-maven-plugin/artifactId
executions
execution
idsetup-environments-for-tests/id
phasepre-integration-test/phase
goals
goalexec/goal
/goals
configuration
executable${bash-executable}/executable
arguments
shell-script${system-test-bin}/setupTestEnvironment.sh/shell-script
path_to_commercial_software_v1${software.location.v1}/path_to_commercial_software_v1
path_to_commercial_software_v2${software.location.v2}/path_to_commercial_software_v2
path_to_commercial_software_v3${software.location.v3}/path_to_commercial_software_v3
path_to_jdk7${path-to-java7}/path_to_jdk7
path_to_jdk8${path-to-java8}/path_to_jdk8
script_to_call_value${script-to-call}/script_to_call_value
/arguments
/configuration
/execution
...
/executions
/plugin
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)
[jira] [Closed] (MSHARED-587) remove logger level API from MessageBuilder
[ https://issues.apache.org/jira/browse/MSHARED-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSHARED-587. - Resolution: Fixed > remove logger level API from MessageBuilder > --- > > Key: MSHARED-587 > URL: https://issues.apache.org/jira/browse/MSHARED-587 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Affects Versions: maven-shared-utils-3.1.0 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: maven-shared-utils-3.2.0 > > > debug(), info() and error() are not intended for messages: they are only > intended for log level displaying from slf4j provider implementation: having > these methods in MessageBuilder is confusing (and hard to explain) > moving them to another interface would make things more clear -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (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=15463010#comment-15463010 ] Robert Patrick edited comment on MNG-6083 at 9/4/16 2:41 PM: - Karl, Comments (mostly) in order... 1.) I only have a profile for it so that I can chain them 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 environments. 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 was (Author: rhpatrick00): 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
[jira] [Comment Edited] (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=15463010#comment-15463010 ] Robert Patrick edited comment on MNG-6083 at 9/4/16 2:30 PM: - 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 environments. 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 was (Author: rhpatrick00): 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...
[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=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 contains
[jira] [Comment Edited] (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=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
[jira] [Comment Edited] (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=15462955#comment-15462955
]
Karl Heinz Marbaise edited comment on MNG-6083 at 9/4/16 1:46 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...
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
[jira] [Issue Comment Deleted] (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: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 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=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=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] [Comment Edited] (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=15462892#comment-15462892 ] Robert Patrick edited comment on MNG-6083 at 9/4/16 1:12 PM: - 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, which includes all modules. We have two main Jenkins job types. One builds the software and runs the unit tests (using the default dev profile) and pushes 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. Our developers can also run the integration tests locally prior to checking in, if they choose. I encourage this on large changes since I "fine" them every time they break a Jenkins nightly build job. 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 was (Author: rhpatrick00): 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
[jira] [Comment Edited] (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=15462892#comment-15462892 ] Robert Patrick edited comment on MNG-6083 at 9/4/16 1:07 PM: - 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 builds the software and runs the unit tests (using the default dev profile) and pushes 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. Our developers can also run the integration tests locally prior to checking in, if they choose. I encourage this on large changes since I "fine" them every time they break a Jenkins nightly build job. 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 was (Author: rhpatrick00): 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
[jira] [Commented] (MSHARED-587) remove logger level API from MessageBuilder
[ https://issues.apache.org/jira/browse/MSHARED-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15462900#comment-15462900 ] Hudson commented on MSHARED-587: SUCCESS: Integrated in Jenkins build maven-shared #2866 (See [https://builds.apache.org/job/maven-shared/2866/]) [MSHARED-587] typos (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1759176]) * (edit) maven-shared-utils/pom.xml * (edit) maven-shared-utils/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java [MSHARED-587] extracted LoggerLevelRenderer interface from MessageBuilder (hboutemy: [http://svn.apache.org/viewvc/?view=rev=1759175]) * (edit) maven-shared-utils/src/main/java/org/apache/maven/shared/utils/logging/AnsiMessageBuilder.java * (add) maven-shared-utils/src/main/java/org/apache/maven/shared/utils/logging/LoggerLevelRenderer.java * (edit) maven-shared-utils/src/main/java/org/apache/maven/shared/utils/logging/MessageBuilder.java * (edit) maven-shared-utils/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java * (edit) maven-shared-utils/src/main/java/org/apache/maven/shared/utils/logging/PlainMessageBuilder.java * (edit) maven-shared-utils/src/main/java/org/apache/maven/shared/utils/logging/Style.java * (edit) maven-shared-utils/src/main/java/org/apache/maven/shared/utils/logging/package-info.java * (edit) maven-shared-utils/src/test/java/org/apache/maven/shared/utils/logging/AnsiMessageBuilderTest.java > remove logger level API from MessageBuilder > --- > > Key: MSHARED-587 > URL: https://issues.apache.org/jira/browse/MSHARED-587 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-shared-utils >Affects Versions: maven-shared-utils-3.1.0 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: maven-shared-utils-3.2.0 > > > debug(), info() and error() are not intended for messages: they are only > intended for log level displaying from slf4j provider implementation: having > these methods in MessageBuilder is confusing (and hard to explain) > moving them to another interface would make things more clear -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (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=15462892#comment-15462892 ] Robert Patrick edited comment on MNG-6083 at 9/4/16 1:03 PM: - 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 builds the software and runs the unit tests (using the default dev profile) and pushes 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 was (Author: rhpatrick00): 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
[jira] [Comment Edited] (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=15462892#comment-15462892 ] Robert Patrick edited comment on MNG-6083 at 9/4/16 1:02 PM: - 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 was (Author: rhpatrick00): 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
[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=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 from 3.3.3 to
[jira] [Created] (MNG-6085) Make the usage of ${project.version} usable in parent element of a multi module build
Karl Heinz Marbaise created MNG-6085:
Summary: Make the usage of ${project.version} usable in parent
element of a multi module build
Key: MNG-6085
URL: https://issues.apache.org/jira/browse/MNG-6085
Project: Maven
Issue Type: Improvement
Components: core
Reporter: Karl Heinz Marbaise
Priority: Minor
Based on [a discussion|MNG-5576] it would be nice to make it possible to use
{{$project.version}} within a parent element which would be more
general solution than with {{$revision}} etc.
The parent:
{code:xml}
<...>
1.3.0-SNAPSHOT
child
...
{code}
{code:xml}
..
..
${project.version}
child
...
{code}
References:
https://issues.apache.org/jira/browse/MNG-5576?focusedCommentId=15448357=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15448357
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (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=15462819#comment-15462819
]
Karl Heinz Marbaise edited comment on MNG-6083 at 9/4/16 12:05 PM:
---
What do you mean by controlling sub modules by profile? You mean things like
this:
{code:xml}
...
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:xml}
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|https://maven.apache.org/guides/mini/guide-using-toolchains.html]?
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
was (Author: khmarbaise):
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
[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=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] [Created] (MSHARED-587) remove logger level API from MessageBuilder
Hervé Boutemy created MSHARED-587: - Summary: remove logger level API from MessageBuilder Key: MSHARED-587 URL: https://issues.apache.org/jira/browse/MSHARED-587 Project: Maven Shared Components Issue Type: Improvement Components: maven-shared-utils Affects Versions: maven-shared-utils-3.1.0 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: maven-shared-utils-3.1.1 debug(), info() and error() are not intended for messages: they are only intended for log level displaying from slf4j provider implementation: having these methods in MessageBuilder is confusing (and hard to explain) moving them to another interface would make things more clear -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1254) add color messages
[ https://issues.apache.org/jira/browse/SUREFIRE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15462522#comment-15462522 ] ASF GitHub Bot commented on SUREFIRE-1254: -- Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/117 @hboutemy I will remove the SPI. The code will be simple if I just move the implementation to `surefire-common`. I thought that `surefire-common` appeared in classpath of forked jvm but I see now the classpath and no such artifact is in there. > add color messages > -- > > Key: SUREFIRE-1254 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1254 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Hervé Boutemy >Assignee: Tibor Digana > Fix For: 2.19.2 > > > with MNG-3507 fixed, adding colors to tests results would improve readability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1254) add color messages
[ https://issues.apache.org/jira/browse/SUREFIRE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15462495#comment-15462495 ] ASF GitHub Bot commented on SUREFIRE-1254: -- Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/117 @hboutemy Hi Herve, I will amend the commit. So one commit would still appear however it is in progress. Surefire report has I think three place with logger only. Maybe important to know. I use ConsoleLogger in with methods like `debug/info/warning/errror` in in-plugin jvm and forked jvm as well. This was here all the history of Surefire but I only extended with few more methods. The implementations should be different in forked-jvm and simply, as higher design principle was, the surefire providers are slaves and they only encode and send a message to main process or receive a command to do. The main process does what it has to do; either creates a report of displays message in console. From the same principle in-plugin jvm is the only place where the ClassLoader should see ANSI and MessageBuilder of m-shared-u. So this separation is safe because such classes will never be loaded or failed to load in forked jvm and this prevents me from having ugly jira issues. So I decided to use SPI to separate implementation which is in surefire-common from surefire-api which is used everywhere. The SPI is a builder of colored messages only. So now we will have logs like `[INFO] Running MyTest` with colors instead of `Running MyTest`. Three advantages: + I fixed the issue you reported https://issues.apache.org/jira/browse/SUREFIRE-1254 + many people reported bug that Surefire writes anything in consolve, so logger will again control the output and we don't have to add configuration parameter in plugin which is good, thus we fixed https://issues.apache.org/jira/browse/SUREFIRE-725 as well + and what I like is peace in code because as I told you before developers come and go to Surefire and everybody solved his problem without maintaining for long time. And that's the reason why logger was sometimes System.out, or System.err, or ConsoleLogger or mojo logger. I like when the code has internal principles that the attitude is just one; unlike use directly worked with stream PrintWriter which was wrapped stream of System.out which disallowed you to use normal logger like in Maven with slf4j and disallowed you to see messages like `[INFO] ...` etc. > add color messages > -- > > Key: SUREFIRE-1254 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1254 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Hervé Boutemy >Assignee: Tibor Digana > Fix For: 2.19.2 > > > with MNG-3507 fixed, adding colors to tests results would improve readability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1254) add color messages
[ https://issues.apache.org/jira/browse/SUREFIRE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15462470#comment-15462470 ] ASF GitHub Bot commented on SUREFIRE-1254: -- Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/117#discussion_r77448156 --- Diff: maven-failsafe-plugin/pom.xml --- @@ -127,6 +127,19 @@ true + +shared-logging-generated-sources --- End diff -- Good point. I used m-shared-u:3.1.0 but there was compilation error I know from branch 3.0-rc1. One class of m-shared-u appeared in another package related to report. I don't remember the name of the class but it can be easily reproduced. This code would have very short life time because we already have branch `3.0-rc1` and one IT should be fixed and Surefire 2.x is gone. > add color messages > -- > > Key: SUREFIRE-1254 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1254 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Hervé Boutemy >Assignee: Tibor Digana > Fix For: 2.19.2 > > > with MNG-3507 fixed, adding colors to tests results would improve readability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1254) add color messages
[
https://issues.apache.org/jira/browse/SUREFIRE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15462465#comment-15462465
]
ASF GitHub Bot commented on SUREFIRE-1254:
--
Github user Tibor17 commented on a diff in the pull request:
https://github.com/apache/maven-surefire/pull/117#discussion_r77448108
--- Diff:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/log/PluginConsoleLogger.java
---
@@ -0,0 +1,126 @@
+package org.apache.maven.plugin.surefire.log;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.apache.maven.plugin.logging.Log;
+import org.apache.maven.surefire.report.ConsoleLogger;
+
+/**
+ * Wrapper logger of miscellaneous (Maven 2.2.1 or 3.1) implementations of
{@link Log}.
+ * Calling {@link Log#isInfoEnabled()} before {@link
Log#info(CharSequence)} due to Maven 2.2.1.
+ *
+ * @author mailto:tibordig...@apache.org;>Tibor Digana
(tibor17)
+ * @since 2.19.2
+ * @see ConsoleLogger
+ */
+public final class PluginConsoleLogger
+implements ConsoleLogger
+{
+private final Log mojoLogger;
+
+public PluginConsoleLogger( Log mojoLogger )
+{
+this.mojoLogger = mojoLogger;
+}
+
+public boolean isDebugEnabled()
+{
+return mojoLogger.isDebugEnabled();
+}
+
+public void debug( String message )
+{
+if ( mojoLogger.isDebugEnabled() )
+{
+mojoLogger.debug( message );
--- End diff --
The purpose is to separate Mojo Logger. I cannot use Mojo in forked JVM.
Many times the code uses the same classes and interfaces in in-plugin tests or
forked-jvm tests but the same classes are extended and behave different in in
these two places however the super type is used eveywhere like polymorphism.
The same happened with ConsoleLogger and it has advantage because all can be
developed independently and the logger would be same (unlike sometimes we used
System.out and Mojo logger or console logger), so now it's only one.
The important things is that `ConsoleLogger` does not need e.g.
`isDebugEnabled` method but `AbstractSurefireMojo` used this for long time, so
I decided to use concrete implementation class of `ConsoleLogger` in MOJO but
that's the second reason to have this class here :)
Unfortunately we use Java 5; otherwise you would see those annotations in
methods implemented from interface via `@Override`.
> add color messages
> --
>
> Key: SUREFIRE-1254
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1254
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Hervé Boutemy
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> with MNG-3507 fixed, adding colors to tests results would improve readability
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1254) add color messages
[
https://issues.apache.org/jira/browse/SUREFIRE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15462384#comment-15462384
]
ASF GitHub Bot commented on SUREFIRE-1254:
--
Github user hboutemy commented on a diff in the pull request:
https://github.com/apache/maven-surefire/pull/117#discussion_r77447554
--- Diff:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/log/PluginConsoleLogger.java
---
@@ -0,0 +1,126 @@
+package org.apache.maven.plugin.surefire.log;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.apache.maven.plugin.logging.Log;
+import org.apache.maven.surefire.report.ConsoleLogger;
+
+/**
+ * Wrapper logger of miscellaneous (Maven 2.2.1 or 3.1) implementations of
{@link Log}.
+ * Calling {@link Log#isInfoEnabled()} before {@link
Log#info(CharSequence)} due to Maven 2.2.1.
+ *
+ * @author mailto:tibordig...@apache.org;>Tibor Digana
(tibor17)
+ * @since 2.19.2
+ * @see ConsoleLogger
+ */
+public final class PluginConsoleLogger
+implements ConsoleLogger
+{
+private final Log mojoLogger;
+
+public PluginConsoleLogger( Log mojoLogger )
+{
+this.mojoLogger = mojoLogger;
+}
+
+public boolean isDebugEnabled()
+{
+return mojoLogger.isDebugEnabled();
+}
+
+public void debug( String message )
+{
+if ( mojoLogger.isDebugEnabled() )
+{
+mojoLogger.debug( message );
--- End diff --
wow, the whole message with debug level color, and more generally each
message with level color? this will give too much color.
I need to see the effective result, but if it's really what I fear, it was
not the intent when adding color to Maven output: the intent is just to have a
few colored words with general normal message (and nothing else than level with
level color)
> add color messages
> --
>
> Key: SUREFIRE-1254
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1254
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Hervé Boutemy
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> with MNG-3507 fixed, adding colors to tests results would improve readability
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1254) add color messages
[ https://issues.apache.org/jira/browse/SUREFIRE-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15462362#comment-15462362 ] ASF GitHub Bot commented on SUREFIRE-1254: -- Github user hboutemy commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/117#discussion_r77447349 --- Diff: maven-failsafe-plugin/pom.xml --- @@ -127,6 +127,19 @@ true + +shared-logging-generated-sources --- End diff -- IMHO, a little comment to explain why the source code is rebuilt here could be useful for future maintainers > add color messages > -- > > Key: SUREFIRE-1254 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1254 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Hervé Boutemy >Assignee: Tibor Digana > Fix For: 2.19.2 > > > with MNG-3507 fixed, adding colors to tests results would improve readability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
