[jira] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://jira.codehaus.org/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340235#comment-340235
]
Karel Piwko commented on MNG-5199:
--
Yes, I believe this is a deficiency in spawned execution environments. There
are more information about Maven execution that could be propagated to outside
world, such as http://jira.codehaus.org/browse/SUREFIRE-790
Return back org.apache.maven.user-settings and
org.apache.maven.global-settings properties
--
Key: MNG-5199
URL: https://jira.codehaus.org/browse/MNG-5199
Project: Maven 2 3
Issue Type: New Feature
Components: Settings
Affects Versions: 3.0.3
Reporter: Karel Piwko
According to discussion at
http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
I'm sure there is a valid use case for the property:
Imagine following:
{code}
mvn -s setting.xml test
{code}
Surefire has no way how to pass the path of the settings.xml in the spawned
process. If the test in spawned process want to for example access remote
repository defined in settings.xml, user has to specify settings.xml path in
the test itself.
However, for the following:
{code}
mvn -Dorg.apache.maven.user-settings=settings.xml test
{code}
This system property can be passed to surefire configuration and propagated
to the Surefire spawned process later on.
Having a system property removes duplication of the environment settings.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-4565) Multiple profile activation conditions does not work
[ https://jira.codehaus.org/browse/MNG-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311779#comment-311779 ] Karel Piwko commented on MNG-4565: -- Guys, you can check following Maven extension https://github.com/kpiwko/el-profile-activator-extension. You just drop two jars into $MAVEN_HOME/lib/ext and you'll get MVEL support in property value. Multiple profile activation conditions does not work Key: MNG-4565 URL: https://jira.codehaus.org/browse/MNG-4565 Project: Maven 2 3 Issue Type: Bug Components: Profiles Affects Versions: 2.2.1 Environment: All platforms. Reporter: Nicholas Allen Fix For: Issues to be reviewed for 3.x According to the documentation at http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html a profile is activated when all activation conditions are met (which makes sense of course). But when I try to use this it does not work. It seems maven does an OR instead of an AND (which is not rearly as useful and is the opposite of what the documentation says at the previous link). For example, if I have one profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os /activation and another profile that is activated like this: activation activeByDefaultfalse/activeByDefault os namelinux/name /os property namerelease/name valuetrue/value /property /activation Then I would expect the second profile to only be activated if the OS is linux and the release property is defined. When I run 'mvn help:active-profiles' however, maven shows that both profiles are active even though the release property is not defined. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-790) Allow forked process to access the Maven session of parent
[ https://jira.codehaus.org/browse/SUREFIRE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283486#comment-283486 ] Karel Piwko commented on SUREFIRE-790: -- Writing a specific plugin does not really help here, because the test itself is responsible for the packaging. If we move this responsibility to the plugin, we would have an intermediate step. This means that we can't update the test from the IDE on-the-fly, we have to store the step result somewhere on the filesystem, etc., making test development much more difficult. Plugin would not be able to build multiple packages, specific packages per container, etc., basically it will loose all advanced Arquillian features. Allow forked process to access the Maven session of parent -- Key: SUREFIRE-790 URL: https://jira.codehaus.org/browse/SUREFIRE-790 Project: Maven Surefire Issue Type: New Feature Components: process forking Affects Versions: 2.10 Reporter: Karel Piwko Forked process should be able to get information from a parent process, which is a Maven build execution. This will allow the test to access information like which pom.xml file being processed, settings.xml and Maven Reactor plugin. This feature is needed to any test which want to interfere with Maven repositories with Aether, for instance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-790) Allow forked process to access the Maven session of parent
[
https://jira.codehaus.org/browse/SUREFIRE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283488#comment-283488
]
Karel Piwko commented on SUREFIRE-790:
--
I've created an implementation of this feature, you can check the code in pull
request https://github.com/apache/maven-surefire/pull/2.
How does it work?
{code:xml}
configuration
propagateExecutionContexttrue/propagateExecutionContext
!-- optional --
executionContextNamespacemaven.execution/executionContextNamespace
/configuration
{code}
This will make following system properties available in either
forked/non-forked tests
* maven.execution.pom - pom.xml file currently executed, e.g. actual pom file
(not the parent for multimodules)
* maven.execution.user-settings - path to user settings.xml (e.g. mvn -s)
* maven.execution.global-settings - path to global settings.xml (e.g. mvn -gs)
* maven.execution.activeProfiles - list of active profiles in the project
* maven.execution.offline - offline flag (e.g. mvn -o)
This extension uses reflection, the very same way as SUREFIRE-121 and requires
Maven 3.0.x to get MavenExecutionRequest object. If will log a failure.
Integration test is included.
As this is disabled by default, I'm convinced that the clean constraint is not
violated.
Allow forked process to access the Maven session of parent
--
Key: SUREFIRE-790
URL: https://jira.codehaus.org/browse/SUREFIRE-790
Project: Maven Surefire
Issue Type: New Feature
Components: process forking
Affects Versions: 2.10
Reporter: Karel Piwko
Forked process should be able to get information from a parent process,
which is a Maven build execution.
This will allow the test to access information like which pom.xml file being
processed, settings.xml and Maven Reactor plugin.
This feature is needed to any test which want to interfere with Maven
repositories with Aether, for instance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-790) Allow forked process to access the Maven session of parent
Allow forked process to access the Maven session of parent -- Key: SUREFIRE-790 URL: https://jira.codehaus.org/browse/SUREFIRE-790 Project: Maven Surefire Issue Type: New Feature Components: process forking Affects Versions: 2.10 Reporter: Karel Piwko Forked process should be able to get information from a parent process, which is a Maven build execution. This will allow the test to access information like which pom.xml file being processed, settings.xml and Maven Reactor plugin. This feature is needed to any test which want to interfere with Maven repositories with Aether, for instance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-790) Allow forked process to access the Maven session of parent
[ https://jira.codehaus.org/browse/SUREFIRE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283408#comment-283408 ] Karel Piwko commented on SUREFIRE-790: -- My specific use case is using Maven together with Arquillian for testing Java EE applications. Arquillian is building the test archive using Java programmatic API (ShrinkWrap), e.g. creating a minimal archive required to reproduce a bug/test a feature. This allows tests to be run much faster and from IDE without any boostrap steps needed. However, it might happen that user have to include a jar file in the test archive. In that case, Aether is used via an ShrinkWrap extension. Aether has no information that Surefire plugin started it, so pom.xml and settings.xml have to be specified once again in the test itself. This leads to: 1/ The information is duplicated 2/ If user activates a profile or pass different settings.xml file, it expects that they will be passed to the test as well. The key here is to be reproducible in both IDE and CLI. We can't simply move to e.g. integration-test where we can expect dependencies are already resolved somewhere in target/directory as this is not the way how neither of the IDEs work. The idea here is to be at least able to access path to settings.xml, pom.xml and activated profiles, so it would be easy to reproduce the same environment in test Aether, no reason to make whole MavenSession serializable although that we be nice. How does this sound to you? Allow forked process to access the Maven session of parent -- Key: SUREFIRE-790 URL: https://jira.codehaus.org/browse/SUREFIRE-790 Project: Maven Surefire Issue Type: New Feature Components: process forking Affects Versions: 2.10 Reporter: Karel Piwko Forked process should be able to get information from a parent process, which is a Maven build execution. This will allow the test to access information like which pom.xml file being processed, settings.xml and Maven Reactor plugin. This feature is needed to any test which want to interfere with Maven repositories with Aether, for instance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
Return back org.apache.maven.user-settings and org.apache.maven.global-settings
properties
--
Key: MNG-5199
URL: https://jira.codehaus.org/browse/MNG-5199
Project: Maven 2 3
Issue Type: New Feature
Components: Settings
Affects Versions: 3.0.3
Reporter: Karel Piwko
According to discussion at
http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html,
I'm sure there is a valid use case for the property:
Imagine following:
{code}
mvn -s setting.xml test
{code}
Surefire has no way how to pass the path of the settings.xml in the spawned
process. If the test in spawned process want to for example access remote
repository defined in settings.xml, user has to specify settings.xml path in
the test itself.
However, for the following:
{code}
mvn -Dorg.apache.maven.user-settings=settings.xml test
{code}
This system property can be passed to surefire configuration and propagated to
the Surefire spawned process later on.
Having a system property removes duplication of the environment settings.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5127) CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
[
https://jira.codehaus.org/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272586#comment-272586
]
Karel Piwko commented on MNG-5127:
--
This behavior makes multi-module project testing/build a mess. See following
example:
Parent(aggregator) pom.xml
{code}
profile
idlinux-64bit/id
activation
property
namearch/name
valuelinux-64bit/value
/property
/activation
modules
modulelin-64/module
modulelin-64-support/module
/modules
profile
idlinux-64bit-foo/id
activation
property
nameactivation/name
valuelinux-64bit-foo/value
/property
/activation
modules
modulelin-64-foo/module
/modules
/profile
profile
idfoo/id
activation
property
nameframework/name
valuefoo/value
/property
/activation
modules
modulefoo/module
modulefoo-common/module
/modules
...other frameworks and archs...
/profile
{code}
Then, every module might have a specific configuration, e.g.
foo/pom.xml:
{code}
profile
idlinux-32bit/id
...
/profile
profile
idlinux-64bit/id
...
/profile
{code}
Now, supposing I want to build framework foo on arch linux-64, I have to do
mvn -Pfoo,linux-64bit,linux-64bit-foo -Dframework=foo -Darch=linux-64
-Dactivation=linux-64-foo install
leading to many profile does not exist errors/warnings.
In ideal Maven world where profile activation is inherited, this would do the
installation:
mvn -Dframework=foo -Darch=linux-64 -Dactivation=linux-64 install
If I stick with the latter, I would have to recopy the activation to every
module where applicable. Then I'll get the configuration from the parent.
If I stick with the former, I would have to remove activation by a property and
enumerate all possible combination as -P activated profiles, ignoring warnings.
Neither of the approaches helps to manage a large project with a single
aggregator.
Note: activation property is there due to
http://jira.codehaus.org/browse/MNG-4565
CLONE - Maven profile activation does not work when profile is defined in
inherited 'parent' pom
Key: MNG-5127
URL: https://jira.codehaus.org/browse/MNG-5127
Project: Maven 2 3
Issue Type: Bug
Reporter: Gilles Scokart
Assignee: John Casey
The goal is to activate a maven profile based on OS user name.
When I create a standalone project with a profile activation, it works,
however, when I define the profile in a parent pom, it is never activated.
this works:
...
profile
idTONY/id
activation
property
nameuser.name/name
valueWINTONY/value
/property
/activation
properties
/properties
So in this case, my profile is activated based on my OS user name
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building Proj1
[INFO] task-segment: [help:active-profiles] (aggregator-style)
[INFO]
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2':
The following profiles are active:
- TONY (source: pom)
--
However, if I now have the profiles definition in the parent pom, it
doesn't work when I build a child project
So the child project references the parent pom containing the profiles and
the activation, but when it is built,
the profile is not activated
PARENT POM:
...
profiles
profile
idTONY/id
activation
property
nameuser.name/name
valueWINTONY/value
/property
/activation
properties
...
CHILD POM (the one being built)
project
parent
groupIdcom.capgemini.be.proj1/groupId
artifactIdparent/artifactId
version4.0.2/version
/parent
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building Proj1 Application
[INFO] task-segment: [help:active-profiles] (aggregator-style)
[INFO]
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2':
There are no active profiles.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-5127) CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
[
https://jira.codehaus.org/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=272586#comment-272586
]
Karel Piwko edited comment on MNG-5127 at 7/7/11 10:54 AM:
---
This behavior makes multi-module project testing/build a mess. See following
example:
Parent(aggregator) pom.xml
{code}
profile
idlinux-64bit/id
activation
property
namearch/name
valuelinux-64bit/value
/property
/activation
modules
modulelin-64/module
modulelin-64-support/module
/modules
profile
idlinux-64bit-foo/id
activation
property
nameactivation/name
valuelinux-64bit-foo/value
/property
/activation
modules
modulelin-64-foo/module
/modules
/profile
profile
idfoo/id
activation
property
nameframework/name
valuefoo/value
/property
/activation
modules
modulefoo/module
modulefoo-common/module
/modules
...other frameworks and archs...
/profile
{code}
Then, every module might have a specific configuration, e.g.
foo/pom.xml:
{code}
profile
idlinux-32bit/id
...
/profile
profile
idlinux-64bit/id
...
/profile
{code}
Now, supposing I want to build framework foo on arch linux-64, I have to do
{code}
mvn -Pfoo,linux-64bit,linux-64bit-foo -Dframework=foo -Darch=linux-64
-Dactivation=linux-64-foo install
{code}
leading to many profile does not exist errors/warnings.
In ideal Maven world where profile activation is inherited, this would do the
installation:
{code}
mvn -Dframework=foo -Darch=linux-64 -Dactivation=linux-64 install
{code}
If I stick with the latter, I would have to recopy the activation to every
module where applicable. Then I'll get the build configuration from the parent.
If I stick with the former, I would have to remove activation by a property and
enumerate all possible combination as -P activated profiles, ignoring warnings.
Neither of the approaches helps to manage a large project with a single
aggregator.
Note: activation property is there due to
http://jira.codehaus.org/browse/MNG-4565
was (Author: kapy):
This behavior makes multi-module project testing/build a mess. See
following example:
Parent(aggregator) pom.xml
{code}
profile
idlinux-64bit/id
activation
property
namearch/name
valuelinux-64bit/value
/property
/activation
modules
modulelin-64/module
modulelin-64-support/module
/modules
profile
idlinux-64bit-foo/id
activation
property
nameactivation/name
valuelinux-64bit-foo/value
/property
/activation
modules
modulelin-64-foo/module
/modules
/profile
profile
idfoo/id
activation
property
nameframework/name
valuefoo/value
/property
/activation
modules
modulefoo/module
modulefoo-common/module
/modules
...other frameworks and archs...
/profile
{code}
Then, every module might have a specific configuration, e.g.
foo/pom.xml:
{code}
profile
idlinux-32bit/id
...
/profile
profile
idlinux-64bit/id
...
/profile
{code}
Now, supposing I want to build framework foo on arch linux-64, I have to do
mvn -Pfoo,linux-64bit,linux-64bit-foo -Dframework=foo -Darch=linux-64
-Dactivation=linux-64-foo install
leading to many profile does not exist errors/warnings.
In ideal Maven world where profile activation is inherited, this would do the
installation:
mvn -Dframework=foo -Darch=linux-64 -Dactivation=linux-64 install
If I stick with the latter, I would have to recopy the activation to every
module where applicable. Then I'll get the configuration from the parent.
If I stick with the former, I would have to remove activation by a property and
enumerate all possible combination as -P activated profiles, ignoring warnings.
Neither of the approaches helps to manage a large project with a single
aggregator.
Note: activation property is there due to
http://jira.codehaus.org/browse/MNG-4565
CLONE - Maven profile activation does not work when profile is defined in
inherited 'parent' pom
Key: MNG-5127
URL: https://jira.codehaus.org/browse/MNG-5127
Project: Maven 2 3
Issue Type: Bug
Reporter: Gilles Scokart
Assignee: John Casey
The goal is to activate a maven profile based on OS user name.
When I create a standalone project with a profile activation, it works,
however, when I define the profile in a parent pom, it is never activated.
this works:
...
profile
idTONY/id
activation
property
nameuser.name/name
