[jira] [Created] (MNG-8188) Property not resolved in profile pluginManagement
Alexis Jehan created MNG-8188:
-
Summary: Property not resolved in profile pluginManagement
Key: MNG-8188
URL: https://issues.apache.org/jira/browse/MNG-8188
Project: Maven
Issue Type: Bug
Components: POM, Profiles
Affects Versions: 3.9.8
Reporter: Alexis Jehan
Attachments: pom.xml
Hello,
Consider the following POM file:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
foo
foo
foo
3.3.1
org.springframework.boot
spring-boot-maven-plugin
${version.spring-boot}
foo
org.springframework.boot
spring-boot-maven-plugin
${version.spring-boot}
{code}
Using this command: {{mvn help:effective-pom}}
The "version.spring-boot" property is resolved in the first case, but not in
the second one. The property should be resolved everywhere.
Snippet of the generated effective POM:
{code:xml}
[…]
foo
org.springframework.boot
spring-boot-maven-plugin
${version.spring-boot}
[…]
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[I] mvnd release:prepare and mvn release:prepare doesn't behave the same [maven-mvnd]
tofflos opened a new issue, #1081: URL: https://github.com/apache/maven-mvnd/issues/1081 The goal release:prepare is interactive and will ask the user questions when running under mvn but not when running under mvnd. Another difference is that mvnd release:prepare will stall when used in conjunction with `git config commit.gpgsign true` even though the gpg passphrase has been "primed" in gpg-agent. ```bash $ mvnd release:prepare [INFO] Processing build on daemon 28cde3f8 [INFO] Scanning for projects... [INFO] BuildTimeEventSpy is registered. [INFO] [INFO] Using the SmartBuilder implementation with a thread count of 3 [INFO] [INFO] --< com.example:app1 >-- [INFO] Building app1 0.0.6-SNAPSHOT [INFO] from pom.xml [INFO] [ jar ]- [INFO] [INFO] --- release:3.1.1:prepare (default-cli) @ app1 --- [INFO] starting prepare goal, composed of 17 phases: check-poms, scm-check-modifications, check-dependency-snapshots, create-backup-poms, map-release-versions, input-variables, map-development-versions, rewrite-poms-for-release, generate-release-poms, run-preparation-goals, scm-commit-release, scm-tag, rewrite-poms-for-development, remove-release-poms, run-completion-goals, scm-commit-development, end-release [INFO] 1/17 prepare:check-poms [INFO] 2/17 prepare:scm-check-modifications [INFO] Verifying that there are no local modifications... [INFO] ignoring changes on: **/pom.xml.releaseBackup, **/pom.xml.next, **/pom.xml.tag, **/pom.xml.branch, **/release.properties, **/pom.xml.backup [INFO] Executing: /bin/sh -c cd '/home/erik/projects/app1' && 'git' 'rev-parse' '--show-prefix' [INFO] Working directory: /home/erik/projects/app1 [INFO] Executing: /bin/sh -c cd '/home/erik/projects/app1' && 'git' 'status' '--porcelain' '.' [INFO] Working directory: /home/erik/projects/app1 [WARNING] Ignoring unrecognized line: ?? release.properties [INFO] 3/17 prepare:check-dependency-snapshots [INFO] Checking dependencies and plugins for snapshots ... [INFO] 4/17 prepare:create-backup-poms [INFO] Creating pom.xml backup with .releaseBackup suffix [INFO] 5/17 prepare:map-release-versions # Stall occurs here. # I waited a few minutes then pressed Ctrl-C a couple of times to cancel the build. ``` ```bash $ mvn --version Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) Maven home: /home/erik/tools/mvn/current Java version: 21.0.3, vendor: Ubuntu, runtime: /usr/lib/jvm/java-21-openjdk-amd64 Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-19041-microsoft", arch: "amd64", family: "unix" ``` ```bash $ mvnd --version Apache Maven Daemon (mvnd) 1.0.1 linux-amd64 native client (621c13a190faf99724130a4dd0b8ec473a9cde44) Terminal: org.jline.terminal.impl.PosixSysTerminal with pty org.jline.terminal.impl.jni.linux.LinuxNativePty Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) Maven home: /home/erik/tools/mvnd/1.0.1/mvn Java version: 21.0.3, vendor: Ubuntu, runtime: /usr/lib/jvm/java-21-openjdk-amd64 Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "4.4.0-19041-microsoft", arch: "amd64", family: "unix" ``` Not related but mvnd and mvn also report Maven Home a bit differently when displaying version information. ```bash ~/.local/bin/mvn -> /home/erik/tools/mvn/current/bin/mvn # Maven home: /home/erik/tools/mvn/current ~/.local/bin/mvnd -> /home/erik/tools/mvnd/current/bin/mvnd # Maven home: /home/erik/tools/mvnd/1.0.1/mvn ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-8188) [REGRESSION] Property not resolved in profile pluginManagement
[
https://issues.apache.org/jira/browse/MNG-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-8188:
Summary: [REGRESSION] Property not resolved in profile pluginManagement
(was: Property not resolved in profile pluginManagement)
> [REGRESSION] Property not resolved in profile pluginManagement
> --
>
> Key: MNG-8188
> URL: https://issues.apache.org/jira/browse/MNG-8188
> Project: Maven
> Issue Type: Bug
> Components: POM, Profiles
>Affects Versions: 3.9.8
>Reporter: Alexis Jehan
>Priority: Major
> Attachments: pom.xml
>
>
> Hello,
> Consider the following POM file:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> foo
> foo
> foo
>
> 3.3.1
>
>
>
>
>
>
> org.springframework.boot
>
> spring-boot-maven-plugin
>
> ${version.spring-boot}
>
>
>
>
>
>
> foo
>
>
>
>
>
> org.springframework.boot
>
> spring-boot-maven-plugin
>
> ${version.spring-boot}
>
>
>
>
>
>
>
> {code}
> Using this command: {{mvn help:effective-pom}}
> The "version.spring-boot" property is resolved in the first case, but not in
> the second one. The property should be resolved everywhere.
> Snippet of the generated effective POM:
> {code:xml}
> […]
>
> foo
>
>
>
>
> org.springframework.boot
> spring-boot-maven-plugin
> ${version.spring-boot}
>
>
>
>
>
> […]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8188) Property not resolved in profile pluginManagement
[
https://issues.apache.org/jira/browse/MNG-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868134#comment-17868134
]
Michael Osipov commented on MNG-8188:
-
[~alexisj], can you identify the first broken 3.9.x version?
> Property not resolved in profile pluginManagement
> -
>
> Key: MNG-8188
> URL: https://issues.apache.org/jira/browse/MNG-8188
> Project: Maven
> Issue Type: Bug
> Components: POM, Profiles
>Affects Versions: 3.9.8
>Reporter: Alexis Jehan
>Priority: Major
> Attachments: pom.xml
>
>
> Hello,
> Consider the following POM file:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> foo
> foo
> foo
>
> 3.3.1
>
>
>
>
>
>
> org.springframework.boot
>
> spring-boot-maven-plugin
>
> ${version.spring-boot}
>
>
>
>
>
>
> foo
>
>
>
>
>
> org.springframework.boot
>
> spring-boot-maven-plugin
>
> ${version.spring-boot}
>
>
>
>
>
>
>
> {code}
> Using this command: {{mvn help:effective-pom}}
> The "version.spring-boot" property is resolved in the first case, but not in
> the second one. The property should be resolved everywhere.
> Snippet of the generated effective POM:
> {code:xml}
> […]
>
> foo
>
>
>
>
> org.springframework.boot
> spring-boot-maven-plugin
> ${version.spring-boot}
>
>
>
>
>
> […]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8188) Property not resolved in profile pluginManagement
[
https://issues.apache.org/jira/browse/MNG-8188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868133#comment-17868133
]
Michael Osipov commented on MNG-8188:
-
I can confirm this. It works with Maven 3.8.8. [~cstamas]
> Property not resolved in profile pluginManagement
> -
>
> Key: MNG-8188
> URL: https://issues.apache.org/jira/browse/MNG-8188
> Project: Maven
> Issue Type: Bug
> Components: POM, Profiles
>Affects Versions: 3.9.8
>Reporter: Alexis Jehan
>Priority: Major
> Attachments: pom.xml
>
>
> Hello,
> Consider the following POM file:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> foo
> foo
> foo
>
> 3.3.1
>
>
>
>
>
>
> org.springframework.boot
>
> spring-boot-maven-plugin
>
> ${version.spring-boot}
>
>
>
>
>
>
> foo
>
>
>
>
>
> org.springframework.boot
>
> spring-boot-maven-plugin
>
> ${version.spring-boot}
>
>
>
>
>
>
>
> {code}
> Using this command: {{mvn help:effective-pom}}
> The "version.spring-boot" property is resolved in the first case, but not in
> the second one. The property should be resolved everywhere.
> Snippet of the generated effective POM:
> {code:xml}
> […]
>
> foo
>
>
>
>
> org.springframework.boot
> spring-boot-maven-plugin
> ${version.spring-boot}
>
>
>
>
>
> […]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
Arvind Joshi created SUREFIRE-2252: -- Summary: Failsafe xml for a test class has results from another class Key: SUREFIRE-2252 URL: https://issues.apache.org/jira/browse/SUREFIRE-2252 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Affects Versions: 3.2.5 Environment: Maven/JUnit5/Mac Reporter: Arvind Joshi Attachments: ClassAIT.java, ClassBIT.java, TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml *Issue* When I execute tests concurrently (at class level), I see the failsafe xmls being generated, but the test methods themselves seem to be mixed up with other classes. *Expectation* Each failsafe xml is unique to a class, which was the case with the JUnit4 provider. *Versions* maven failsafe plugin 3.2.5 JUnit 5.10.2 *Sample code and Test results* Please see attached files -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
[ https://issues.apache.org/jira/browse/SUREFIRE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arvind Joshi updated SUREFIRE-2252: --- Description: *Issue* When I execute tests concurrently (at class level), I see the failsafe xmls being generated, but the test methods themselves seem to be mixed up with other classes. *Expectation* Each failsafe xml is unique to a class, which was the case with the JUnit4 provider. *Versions* maven failsafe plugin 3.2.5 JUnit 5.10.2 *Sample code and Test results* Please see attached files *Running the tests attached* ``` ``` was: *Issue* When I execute tests concurrently (at class level), I see the failsafe xmls being generated, but the test methods themselves seem to be mixed up with other classes. *Expectation* Each failsafe xml is unique to a class, which was the case with the JUnit4 provider. *Versions* maven failsafe plugin 3.2.5 JUnit 5.10.2 *Sample code and Test results* Please see attached files > Failsafe xml for a test class has results from another class > > > Key: SUREFIRE-2252 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2252 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.2.5 > Environment: Maven/JUnit5/Mac >Reporter: Arvind Joshi >Priority: Major > Attachments: ClassAIT.java, ClassBIT.java, > TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml > > > *Issue* > When I execute tests concurrently (at class level), I see the failsafe xmls > being generated, but the test methods themselves seem to be mixed up with > other classes. > *Expectation* > Each failsafe xml is unique to a class, which was the case with the JUnit4 > provider. > *Versions* > maven failsafe plugin 3.2.5 > JUnit 5.10.2 > *Sample code and Test results* > Please see attached files > *Running the tests attached* > ``` > > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
[ https://issues.apache.org/jira/browse/SUREFIRE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arvind Joshi updated SUREFIRE-2252: --- Description: *Issue* When I execute tests concurrently (at class level), I see the failsafe xmls being generated, but the test methods themselves seem to be mixed up with other classes. *Expectation* Each failsafe xml is unique to a class, which was the case with the JUnit4 provider. *Versions* maven failsafe plugin 3.2.5 JUnit 5.10.2 *Sample code and Test results* Please see attached files *Running the tests attached* `mvn clean verify -Pparallel-tests` ``` [INFO] --- [INFO] T E S T S [INFO] --- [INFO] Running org.example.ClassBIT [INFO] Running org.example.ClassAIT [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s -- in org.example.ClassAIT [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s -- in org.example.ClassBIT ``` was: *Issue* When I execute tests concurrently (at class level), I see the failsafe xmls being generated, but the test methods themselves seem to be mixed up with other classes. *Expectation* Each failsafe xml is unique to a class, which was the case with the JUnit4 provider. *Versions* maven failsafe plugin 3.2.5 JUnit 5.10.2 *Sample code and Test results* Please see attached files *Running the tests attached* ``` ``` > Failsafe xml for a test class has results from another class > > > Key: SUREFIRE-2252 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2252 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.2.5 > Environment: Maven/JUnit5/Mac >Reporter: Arvind Joshi >Priority: Major > Attachments: ClassAIT.java, ClassBIT.java, > TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml > > > *Issue* > When I execute tests concurrently (at class level), I see the failsafe xmls > being generated, but the test methods themselves seem to be mixed up with > other classes. > *Expectation* > Each failsafe xml is unique to a class, which was the case with the JUnit4 > provider. > *Versions* > maven failsafe plugin 3.2.5 > JUnit 5.10.2 > *Sample code and Test results* > Please see attached files > *Running the tests attached* > `mvn clean verify -Pparallel-tests` > ``` > [INFO] --- > [INFO] T E S T S > [INFO] --- > [INFO] Running org.example.ClassBIT > [INFO] Running org.example.ClassAIT > [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 > s -- in org.example.ClassAIT > [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 > s -- in org.example.ClassBIT > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
[ https://issues.apache.org/jira/browse/SUREFIRE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arvind Joshi updated SUREFIRE-2252: --- Description: *Issue* When I execute tests concurrently (at class level), I see the failsafe xmls being generated, but the test methods themselves seem to be mixed up with other classes. *Expectation* Each failsafe xml is unique to a class, which was the case with the JUnit4 provider. *Versions* maven failsafe plugin 3.2.5 JUnit 5.10.2 *Sample code and Test results* Please see attached files *Running the tests attached* `mvn clean verify -Pparallel-tests` ``` [INFO] --- [INFO] T E S T S [INFO] --- [INFO] Running org.example.ClassBIT [INFO] Running org.example.ClassAIT [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s – in org.example.ClassAIT [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s – in org.example.ClassBIT [INFO] [INFO] Results: [INFO] [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 ``` was: *Issue* When I execute tests concurrently (at class level), I see the failsafe xmls being generated, but the test methods themselves seem to be mixed up with other classes. *Expectation* Each failsafe xml is unique to a class, which was the case with the JUnit4 provider. *Versions* maven failsafe plugin 3.2.5 JUnit 5.10.2 *Sample code and Test results* Please see attached files *Running the tests attached* `mvn clean verify -Pparallel-tests` ``` [INFO] --- [INFO] T E S T S [INFO] --- [INFO] Running org.example.ClassBIT [INFO] Running org.example.ClassAIT [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s -- in org.example.ClassAIT [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s -- in org.example.ClassBIT ``` > Failsafe xml for a test class has results from another class > > > Key: SUREFIRE-2252 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2252 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.2.5 > Environment: Maven/JUnit5/Mac >Reporter: Arvind Joshi >Priority: Major > Attachments: ClassAIT.java, ClassBIT.java, > TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml > > > *Issue* > When I execute tests concurrently (at class level), I see the failsafe xmls > being generated, but the test methods themselves seem to be mixed up with > other classes. > *Expectation* > Each failsafe xml is unique to a class, which was the case with the JUnit4 > provider. > *Versions* > maven failsafe plugin 3.2.5 > JUnit 5.10.2 > *Sample code and Test results* > Please see attached files > *Running the tests attached* > `mvn clean verify -Pparallel-tests` > ``` > [INFO] --- > [INFO] T E S T S > [INFO] --- > [INFO] Running org.example.ClassBIT > [INFO] Running org.example.ClassAIT > [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 > s – in org.example.ClassAIT > [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 > s – in org.example.ClassBIT > [INFO] > [INFO] Results: > [INFO] > [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0 > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
[
https://issues.apache.org/jira/browse/SUREFIRE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arvind Joshi updated SUREFIRE-2252:
---
Description:
*Issue*
When I execute tests concurrently (at class level), I see the failsafe xmls
being generated, but the test methods themselves seem to be mixed up with other
classes.
*Expectation*
Each failsafe xml is unique to a class, which was the case with the JUnit4
provider.
*Versions*
maven failsafe plugin 3.2.5
JUnit 5.10.2
*Sample code and Test results*
Please see attached files
*Running the tests attached*
{noformat}
mvn clean verify -Pparallel-tests{noformat}
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.ClassBIT
[INFO] Running org.example.ClassAIT
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s
– in org.example.ClassAIT
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s
– in org.example.ClassBIT
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0{noformat}
was:
*Issue*
When I execute tests concurrently (at class level), I see the failsafe xmls
being generated, but the test methods themselves seem to be mixed up with other
classes.
*Expectation*
Each failsafe xml is unique to a class, which was the case with the JUnit4
provider.
*Versions*
maven failsafe plugin 3.2.5
JUnit 5.10.2
*Sample code and Test results*
Please see attached files
*Running the tests attached*
`mvn clean verify -Pparallel-tests`
```
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.ClassBIT
[INFO] Running org.example.ClassAIT
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s
– in org.example.ClassAIT
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s
– in org.example.ClassBIT
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
```
> Failsafe xml for a test class has results from another class
>
>
> Key: SUREFIRE-2252
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2252
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.2.5
> Environment: Maven/JUnit5/Mac
>Reporter: Arvind Joshi
>Priority: Major
> Attachments: ClassAIT.java, ClassBIT.java,
> TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml
>
>
> *Issue*
> When I execute tests concurrently (at class level), I see the failsafe xmls
> being generated, but the test methods themselves seem to be mixed up with
> other classes.
> *Expectation*
> Each failsafe xml is unique to a class, which was the case with the JUnit4
> provider.
> *Versions*
> maven failsafe plugin 3.2.5
> JUnit 5.10.2
> *Sample code and Test results*
> Please see attached files
> *Running the tests attached*
>
> {noformat}
> mvn clean verify -Pparallel-tests{noformat}
>
>
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.ClassBIT
> [INFO] Running org.example.ClassAIT
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassAIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassBIT
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
[
https://issues.apache.org/jira/browse/SUREFIRE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arvind Joshi updated SUREFIRE-2252:
---
Description:
*Issue*
When I execute tests concurrently (at class level), I see the failsafe xmls
being generated, but the test methods themselves seem to be mixed up with other
classes.
*Expectation*
Each failsafe xml is unique to a class, which was the case with the JUnit4
provider.
*Versions*
maven failsafe plugin 3.2.5 or 3.3.1
JUnit 5.10.2
*Sample code and Test results*
Please see attached files
*Running the tests attached*
{noformat}
mvn clean verify -Pparallel-tests{noformat}
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.ClassBIT
[INFO] Running org.example.ClassAIT
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s
– in org.example.ClassAIT
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s
– in org.example.ClassBIT
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0{noformat}
was:
*Issue*
When I execute tests concurrently (at class level), I see the failsafe xmls
being generated, but the test methods themselves seem to be mixed up with other
classes.
*Expectation*
Each failsafe xml is unique to a class, which was the case with the JUnit4
provider.
*Versions*
maven failsafe plugin 3.2.5
JUnit 5.10.2
*Sample code and Test results*
Please see attached files
*Running the tests attached*
{noformat}
mvn clean verify -Pparallel-tests{noformat}
{noformat}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running org.example.ClassBIT
[INFO] Running org.example.ClassAIT
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s
– in org.example.ClassAIT
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 s
– in org.example.ClassBIT
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0{noformat}
> Failsafe xml for a test class has results from another class
>
>
> Key: SUREFIRE-2252
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2252
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.2.5
> Environment: Maven/JUnit5/Mac
>Reporter: Arvind Joshi
>Priority: Major
> Attachments: ClassAIT.java, ClassBIT.java,
> TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml
>
>
> *Issue*
> When I execute tests concurrently (at class level), I see the failsafe xmls
> being generated, but the test methods themselves seem to be mixed up with
> other classes.
> *Expectation*
> Each failsafe xml is unique to a class, which was the case with the JUnit4
> provider.
> *Versions*
> maven failsafe plugin 3.2.5 or 3.3.1
> JUnit 5.10.2
> *Sample code and Test results*
> Please see attached files
> *Running the tests attached*
>
> {noformat}
> mvn clean verify -Pparallel-tests{noformat}
>
>
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.ClassBIT
> [INFO] Running org.example.ClassAIT
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassAIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassBIT
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
[
https://issues.apache.org/jira/browse/SUREFIRE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arvind Joshi updated SUREFIRE-2252:
---
Attachment: pom.xml
> Failsafe xml for a test class has results from another class
>
>
> Key: SUREFIRE-2252
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2252
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.2.5
> Environment: Maven/JUnit5/Mac
>Reporter: Arvind Joshi
>Priority: Major
> Attachments: ClassAIT.java, ClassBIT.java,
> TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml
>
>
> *Issue*
> When I execute tests concurrently (at class level), I see the failsafe xmls
> being generated, but the test methods themselves seem to be mixed up with
> other classes.
> *Expectation*
> Each failsafe xml is unique to a class, which was the case with the JUnit4
> provider.
> *Versions*
> maven failsafe plugin 3.2.5 or 3.3.1
> JUnit 5.10.2
> *Sample code and Test results*
> Please see attached files
> *Running the tests attached*
>
> {noformat}
> mvn clean verify -Pparallel-tests{noformat}
>
>
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.ClassBIT
> [INFO] Running org.example.ClassAIT
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassAIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassBIT
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
[
https://issues.apache.org/jira/browse/SUREFIRE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arvind Joshi updated SUREFIRE-2252:
---
Attachment: (was: pom.xml)
> Failsafe xml for a test class has results from another class
>
>
> Key: SUREFIRE-2252
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2252
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.2.5
> Environment: Maven/JUnit5/Mac
>Reporter: Arvind Joshi
>Priority: Major
> Attachments: ClassAIT.java, ClassBIT.java,
> TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml
>
>
> *Issue*
> When I execute tests concurrently (at class level), I see the failsafe xmls
> being generated, but the test methods themselves seem to be mixed up with
> other classes.
> *Expectation*
> Each failsafe xml is unique to a class, which was the case with the JUnit4
> provider.
> *Versions*
> maven failsafe plugin 3.2.5 or 3.3.1
> JUnit 5.10.2
> *Sample code and Test results*
> Please see attached files
> *Running the tests attached*
>
> {noformat}
> mvn clean verify -Pparallel-tests{noformat}
>
>
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.ClassBIT
> [INFO] Running org.example.ClassAIT
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassAIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassBIT
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2252) Failsafe xml for a test class has results from another class
[
https://issues.apache.org/jira/browse/SUREFIRE-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SUREFIRE-2252:
-
Affects Version/s: 3.3.1
> Failsafe xml for a test class has results from another class
>
>
> Key: SUREFIRE-2252
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2252
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.2.5, 3.3.1
> Environment: Maven/JUnit5/Mac
>Reporter: Arvind Joshi
>Priority: Major
> Attachments: ClassAIT.java, ClassBIT.java,
> TEST-org.example.ClassAIT.xml, TEST-org.example.ClassBIT.xml, pom.xml
>
>
> *Issue*
> When I execute tests concurrently (at class level), I see the failsafe xmls
> being generated, but the test methods themselves seem to be mixed up with
> other classes.
> *Expectation*
> Each failsafe xml is unique to a class, which was the case with the JUnit4
> provider.
> *Versions*
> maven failsafe plugin 3.2.5 or 3.3.1
> JUnit 5.10.2
> *Sample code and Test results*
> Please see attached files
> *Running the tests attached*
>
> {noformat}
> mvn clean verify -Pparallel-tests{noformat}
>
>
> {noformat}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running org.example.ClassBIT
> [INFO] Running org.example.ClassAIT
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassAIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026
> s – in org.example.ClassBIT
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite [maven-surefire]
michael-o commented on PR #762: URL: https://github.com/apache/maven-surefire/pull/762#issuecomment-2246228576 I read the JIRA description and this PR. My first problem: Where is the documentation that user properties are passed to Surefire at all? Here: https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#systemPropertyVariables I see zero of the Javadoc. That is a serious problem for starters... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868175#comment-17868175
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
michael-o commented on PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#issuecomment-2246228576
I read the JIRA description and this PR. My first problem: Where is the
documentation that user properties are passed to Surefire at all? Here:
https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#systemPropertyVariables
I see zero of the Javadoc. That is a serious problem for starters...
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Maven with that other name and compromise
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe
> Plugin take precedence over user properties passed on the command line.
> Proposed commit
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/4de017b3]
> on SUREFIRE-1385 branch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite [maven-surefire]
michael-o commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1678243230
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,49 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven
process
+ * {@link #userPropertyVariables}
*
* Later sources may overwrite same named properties from earlier sources,
that means for example that one cannot overwrite user properties with either
- * {@link #systemProperties}, {@link
AbstractSurefireMojo#getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ * {@link #systemProperties}, {@link #getSystemPropertiesFile()} or {@link
#systemPropertyVariables} but only with
+ * {@link #userPropertyVariables}.
+ *
+ * Certain properties may only be overwritten via {@link #argLine}
(applicable only for forked executions) because their values are cached and
only evaluated at the start of the JRE.
+ * Those include:
+ *
+ * {@code java.library.path}
+ * {@code file.encoding}
+ * {@code jdk.map.althashing.threshold}
+ * {@code line.separator}
+ *
*
* @since 2.5
* @see #systemProperties
*/
@Parameter
-private Map systemPropertyVariables;
+Map systemPropertyVariables;
+
+/**
+ * List of user properties to pass to a provider.
+ * Similar to {@link #systemPropertyVariables} but having a higher
precedence, therefore allows to overwrite user properties from the current
Maven session.
+ * This should only be used in case a user property from the parent
process needs to be explicitly overwritten.
+ * Regular properties should be set via {@link #systemPropertyVariables}
instead in order to allow them to be overwritten
+ * via CLI arguments ({@code -Dmyproperty=myvalue})
+ * @since 3.4
+ * @see #systemPropertyVariables
+ */
+@Parameter
+Map userPropertyVariables;
Review Comment:
My abstract understanding:
* system properties (include MAVEN_OPTS logically)
* system properties file
* system property variables in POM
* user properties file
* user property variables in POM
* user properties from CLI
WDYT?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868177#comment-17868177
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
michael-o commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1678243230
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,49 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven
process
+ * {@link #userPropertyVariables}
*
* Later sources may overwrite same named properties from earlier sources,
that means for example that one cannot overwrite user properties with either
- * {@link #systemProperties}, {@link
AbstractSurefireMojo#getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ * {@link #systemProperties}, {@link #getSystemPropertiesFile()} or {@link
#systemPropertyVariables} but only with
+ * {@link #userPropertyVariables}.
+ *
+ * Certain properties may only be overwritten via {@link #argLine}
(applicable only for forked executions) because their values are cached and
only evaluated at the start of the JRE.
+ * Those include:
+ *
+ * {@code java.library.path}
+ * {@code file.encoding}
+ * {@code jdk.map.althashing.threshold}
+ * {@code line.separator}
+ *
*
* @since 2.5
* @see #systemProperties
*/
@Parameter
-private Map systemPropertyVariables;
+Map systemPropertyVariables;
+
+/**
+ * List of user properties to pass to a provider.
+ * Similar to {@link #systemPropertyVariables} but having a higher
precedence, therefore allows to overwrite user properties from the current
Maven session.
+ * This should only be used in case a user property from the parent
process needs to be explicitly overwritten.
+ * Regular properties should be set via {@link #systemPropertyVariables}
instead in order to allow them to be overwritten
+ * via CLI arguments ({@code -Dmyproperty=myvalue})
+ * @since 3.4
+ * @see #systemPropertyVariables
+ */
+@Parameter
+Map userPropertyVariables;
Review Comment:
My abstract understanding:
* system properties (include MAVEN_OPTS logically)
* system properties file
* system property variables in POM
* user properties file
* user property variables in POM
* user properties from CLI
WDYT?
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Mav
Re: [PR] [SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite [maven-surefire]
michael-o commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1688670224
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1184,6 +1208,39 @@ private SurefireProperties setupProperties() {
return result;
}
+private SurefireProperties calculateEffectiveProperties(
+Properties systemProperties,
+Map systemPropertyVariables,
+Properties userProperties,
+SurefireProperties sysPropsFromFile) {
+SurefireProperties result = new SurefireProperties();
+result.copyPropertiesFrom(systemProperties);
+
+Collection overwrittenProperties =
result.copyPropertiesFrom(sysPropsFromFile);
+if (!overwrittenProperties.isEmpty() &&
getConsoleLogger().isDebugEnabled()) {
+
getConsoleLogger().debug(getOverwrittenPropertiesLogMessage(overwrittenProperties,
"sysPropsFile"));
Review Comment:
The parameter name is `systemPropertiesFile` and this is what I would pass
here to avoid confusion
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1184,6 +1208,39 @@ private SurefireProperties setupProperties() {
return result;
}
+private SurefireProperties calculateEffectiveProperties(
+Properties systemProperties,
+Map systemPropertyVariables,
+Properties userProperties,
+SurefireProperties sysPropsFromFile) {
+SurefireProperties result = new SurefireProperties();
+result.copyPropertiesFrom(systemProperties);
+
+Collection overwrittenProperties =
result.copyPropertiesFrom(sysPropsFromFile);
+if (!overwrittenProperties.isEmpty() &&
getConsoleLogger().isDebugEnabled()) {
+
getConsoleLogger().debug(getOverwrittenPropertiesLogMessage(overwrittenProperties,
"sysPropsFile"));
+}
+overwrittenProperties =
result.copyPropertiesFrom(systemPropertyVariables);
+if (!overwrittenProperties.isEmpty() &&
getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()
+
.debug(getOverwrittenPropertiesLogMessage(overwrittenProperties,
"systemPropertyVariables"));
+}
+// We used to take all of our system properties and dump them in with
the
+// user specified properties for SUREFIRE-121, causing SUREFIRE-491.
+// Not gonna do THAT any more... instead, we only propagate those
system properties
+// that have been explicitly specified by the user via -Dkey=value on
the CLI
+// and only if useUserPropertiesAsSystemProperty is set to true
Review Comment:
I believe that this comment is redundant because wether or not user
properties have been passed is at the discretion of the caller. This method
shouldn' care about the decision logic.
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1152,8 +1173,11 @@ private SurefireProperties setupProperties() {
}
}
-SurefireProperties result =
SurefireProperties.calculateEffectiveProperties(
-getSystemProperties(), getSystemPropertyVariables(),
getUserProperties(), sysProps);
+SurefireProperties result = calculateEffectiveProperties(
+getSystemProperties(),
+getSystemPropertyVariables(),
+useUserPropertiesAsSystemProperty ? getUserProperties() : null,
Review Comment:
Wouldn't it be better, for consistency reasons, to pass empty properties
here instead of `null`. That makes the code more consistent with the other
sources.
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,44 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven process
(only used as source if {@link #useUserPropertiesAsSystemProperty} is {@code
true})
*
* Later sources may overwrite s
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868179#comment-17868179
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
michael-o commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1688670224
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1184,6 +1208,39 @@ private SurefireProperties setupProperties() {
return result;
}
+private SurefireProperties calculateEffectiveProperties(
+Properties systemProperties,
+Map systemPropertyVariables,
+Properties userProperties,
+SurefireProperties sysPropsFromFile) {
+SurefireProperties result = new SurefireProperties();
+result.copyPropertiesFrom(systemProperties);
+
+Collection overwrittenProperties =
result.copyPropertiesFrom(sysPropsFromFile);
+if (!overwrittenProperties.isEmpty() &&
getConsoleLogger().isDebugEnabled()) {
+
getConsoleLogger().debug(getOverwrittenPropertiesLogMessage(overwrittenProperties,
"sysPropsFile"));
Review Comment:
The parameter name is `systemPropertiesFile` and this is what I would pass
here to avoid confusion
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1184,6 +1208,39 @@ private SurefireProperties setupProperties() {
return result;
}
+private SurefireProperties calculateEffectiveProperties(
+Properties systemProperties,
+Map systemPropertyVariables,
+Properties userProperties,
+SurefireProperties sysPropsFromFile) {
+SurefireProperties result = new SurefireProperties();
+result.copyPropertiesFrom(systemProperties);
+
+Collection overwrittenProperties =
result.copyPropertiesFrom(sysPropsFromFile);
+if (!overwrittenProperties.isEmpty() &&
getConsoleLogger().isDebugEnabled()) {
+
getConsoleLogger().debug(getOverwrittenPropertiesLogMessage(overwrittenProperties,
"sysPropsFile"));
+}
+overwrittenProperties =
result.copyPropertiesFrom(systemPropertyVariables);
+if (!overwrittenProperties.isEmpty() &&
getConsoleLogger().isDebugEnabled()) {
+getConsoleLogger()
+
.debug(getOverwrittenPropertiesLogMessage(overwrittenProperties,
"systemPropertyVariables"));
+}
+// We used to take all of our system properties and dump them in with
the
+// user specified properties for SUREFIRE-121, causing SUREFIRE-491.
+// Not gonna do THAT any more... instead, we only propagate those
system properties
+// that have been explicitly specified by the user via -Dkey=value on
the CLI
+// and only if useUserPropertiesAsSystemProperty is set to true
Review Comment:
I believe that this comment is redundant because wether or not user
properties have been passed is at the discretion of the caller. This method
shouldn' care about the decision logic.
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -1152,8 +1173,11 @@ private SurefireProperties setupProperties() {
}
}
-SurefireProperties result =
SurefireProperties.calculateEffectiveProperties(
-getSystemProperties(), getSystemPropertyVariables(),
getUserProperties(), sysProps);
+SurefireProperties result = calculateEffectiveProperties(
+getSystemProperties(),
+getSystemPropertyVariables(),
+useUserPropertiesAsSystemProperty ? getUserProperties() : null,
Review Comment:
Wouldn't it be better, for consistency reasons, to pass empty properties
here instead of `null`. That makes the code more consistent with the other
sources.
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,44 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User proper
Re: [PR] [SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite [maven-surefire]
michael-o commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1688677896
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,49 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven
process
+ * {@link #userPropertyVariables}
*
* Later sources may overwrite same named properties from earlier sources,
that means for example that one cannot overwrite user properties with either
- * {@link #systemProperties}, {@link
AbstractSurefireMojo#getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ * {@link #systemProperties}, {@link #getSystemPropertiesFile()} or {@link
#systemPropertyVariables} but only with
+ * {@link #userPropertyVariables}.
+ *
+ * Certain properties may only be overwritten via {@link #argLine}
(applicable only for forked executions) because their values are cached and
only evaluated at the start of the JRE.
+ * Those include:
+ *
+ * {@code java.library.path}
+ * {@code file.encoding}
+ * {@code jdk.map.althashing.threshold}
+ * {@code line.separator}
+ *
*
* @since 2.5
* @see #systemProperties
*/
@Parameter
-private Map systemPropertyVariables;
+Map systemPropertyVariables;
+
+/**
+ * List of user properties to pass to a provider.
+ * Similar to {@link #systemPropertyVariables} but having a higher
precedence, therefore allows to overwrite user properties from the current
Maven session.
+ * This should only be used in case a user property from the parent
process needs to be explicitly overwritten.
+ * Regular properties should be set via {@link #systemPropertyVariables}
instead in order to allow them to be overwritten
+ * via CLI arguments ({@code -Dmyproperty=myvalue})
+ * @since 3.4
+ * @see #systemPropertyVariables
+ */
+@Parameter
+Map userPropertyVariables;
Review Comment:
@slawekjaranowski I agree with you that passing user properties by default
is a bad idea.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868180#comment-17868180
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
kwin commented on PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#issuecomment-2246253490
I already extended the javadoc in
https://github.com/apache/maven-surefire/commit/cd72eaa0f1e2c2c8d41e643ae5bcfbcb4e36f8ed
(you reviewed and approved) but for me this is only remotely related to this
PR.
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Maven with that other name and compromise
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe
> Plugin take precedence over user properties passed on the command line.
> Proposed commit
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/4de017b3]
> on SUREFIRE-1385 branch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868181#comment-17868181
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
michael-o commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1688677896
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,49 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven
process
+ * {@link #userPropertyVariables}
*
* Later sources may overwrite same named properties from earlier sources,
that means for example that one cannot overwrite user properties with either
- * {@link #systemProperties}, {@link
AbstractSurefireMojo#getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ * {@link #systemProperties}, {@link #getSystemPropertiesFile()} or {@link
#systemPropertyVariables} but only with
+ * {@link #userPropertyVariables}.
+ *
+ * Certain properties may only be overwritten via {@link #argLine}
(applicable only for forked executions) because their values are cached and
only evaluated at the start of the JRE.
+ * Those include:
+ *
+ * {@code java.library.path}
+ * {@code file.encoding}
+ * {@code jdk.map.althashing.threshold}
+ * {@code line.separator}
+ *
*
* @since 2.5
* @see #systemProperties
*/
@Parameter
-private Map systemPropertyVariables;
+Map systemPropertyVariables;
+
+/**
+ * List of user properties to pass to a provider.
+ * Similar to {@link #systemPropertyVariables} but having a higher
precedence, therefore allows to overwrite user properties from the current
Maven session.
+ * This should only be used in case a user property from the parent
process needs to be explicitly overwritten.
+ * Regular properties should be set via {@link #systemPropertyVariables}
instead in order to allow them to be overwritten
+ * via CLI arguments ({@code -Dmyproperty=myvalue})
+ * @since 3.4
+ * @see #systemPropertyVariables
+ */
+@Parameter
+Map userPropertyVariables;
Review Comment:
@slawekjaranowski I agree with you that passing user properties by default
is a bad idea.
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Maven with that other name and compromise
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{syst
Re: [PR] [SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite [maven-surefire]
kwin commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1688679394
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,44 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven process
(only used as source if {@link #useUserPropertiesAsSystemProperty} is {@code
true})
*
* Later sources may overwrite same named properties from earlier sources,
that means for example that one cannot overwrite user properties with either
- * {@link #systemProperties}, {@link
AbstractSurefireMojo#getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ * {@link #systemProperties}, {@link #getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ *
+ * Certain properties may only be overwritten via {@link #argLine}
(applicable only for forked executions) because their values are cached and
only evaluated at the start of the JRE.
+ * Those include:
+ *
+ * {@code java.library.path}
+ * {@code file.encoding}
+ * {@code jdk.map.althashing.threshold}
+ * {@code line.separator}
+ *
*
* @since 2.5
* @see #systemProperties
*/
@Parameter
-private Map systemPropertyVariables;
+Map systemPropertyVariables;
+
+/**
+ * If set to {@code true} will also pass all user properties exposed via
{@link MavenSession#getUserProperties()} as system properties to a provider.
+ * Those always take precedence over same named system properties set via
any other means.
+ * @since 3.4.0
+ * @see #systemPropertyVariables
+ */
+@Parameter(defaultValue = "true")
+boolean useUserPropertiesAsSystemProperty;
Review Comment:
maybe `addUserPropertiesToSystemProperties` is even better
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite [maven-surefire]
michael-o commented on PR #762: URL: https://github.com/apache/maven-surefire/pull/762#issuecomment-2246256030 > I already extended the javadoc in [cd72eaa](https://github.com/apache/maven-surefire/commit/cd72eaa0f1e2c2c8d41e643ae5bcfbcb4e36f8ed) (you reviewed and approved) but for me this is only remotely related to this PR. Ah, yes now I see. This makes sense. It was merely a side comment. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868182#comment-17868182
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
kwin commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1688679394
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,44 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven process
(only used as source if {@link #useUserPropertiesAsSystemProperty} is {@code
true})
*
* Later sources may overwrite same named properties from earlier sources,
that means for example that one cannot overwrite user properties with either
- * {@link #systemProperties}, {@link
AbstractSurefireMojo#getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ * {@link #systemProperties}, {@link #getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ *
+ * Certain properties may only be overwritten via {@link #argLine}
(applicable only for forked executions) because their values are cached and
only evaluated at the start of the JRE.
+ * Those include:
+ *
+ * {@code java.library.path}
+ * {@code file.encoding}
+ * {@code jdk.map.althashing.threshold}
+ * {@code line.separator}
+ *
*
* @since 2.5
* @see #systemProperties
*/
@Parameter
-private Map systemPropertyVariables;
+Map systemPropertyVariables;
+
+/**
+ * If set to {@code true} will also pass all user properties exposed via
{@link MavenSession#getUserProperties()} as system properties to a provider.
+ * Those always take precedence over same named system properties set via
any other means.
+ * @since 3.4.0
+ * @see #systemPropertyVariables
+ */
+@Parameter(defaultValue = "true")
+boolean useUserPropertiesAsSystemProperty;
Review Comment:
maybe `addUserPropertiesToSystemProperties` is even better
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Maven with that other name and compromise
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe
> Plugin take precedence over user properties passed on the command line.
> Proposed commit
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868183#comment-17868183
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
michael-o commented on PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#issuecomment-2246256030
> I already extended the javadoc in
[cd72eaa](https://github.com/apache/maven-surefire/commit/cd72eaa0f1e2c2c8d41e643ae5bcfbcb4e36f8ed)
(you reviewed and approved) but for me this is only remotely related to this
PR.
Ah, yes now I see. This makes sense. It was merely a side comment.
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Maven with that other name and compromise
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe
> Plugin take precedence over user properties passed on the command line.
> Proposed commit
> [4de017b38b101b0b28f9fbed135eae3921b99d0d|http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/4de017b3]
> on SUREFIRE-1385 branch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite [maven-surefire]
michael-o commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1688680611
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,44 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven process
(only used as source if {@link #useUserPropertiesAsSystemProperty} is {@code
true})
*
* Later sources may overwrite same named properties from earlier sources,
that means for example that one cannot overwrite user properties with either
- * {@link #systemProperties}, {@link
AbstractSurefireMojo#getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ * {@link #systemProperties}, {@link #getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ *
+ * Certain properties may only be overwritten via {@link #argLine}
(applicable only for forked executions) because their values are cached and
only evaluated at the start of the JRE.
+ * Those include:
+ *
+ * {@code java.library.path}
+ * {@code file.encoding}
+ * {@code jdk.map.althashing.threshold}
+ * {@code line.separator}
+ *
*
* @since 2.5
* @see #systemProperties
*/
@Parameter
-private Map systemPropertyVariables;
+Map systemPropertyVariables;
+
+/**
+ * If set to {@code true} will also pass all user properties exposed via
{@link MavenSession#getUserProperties()} as system properties to a provider.
+ * Those always take precedence over same named system properties set via
any other means.
+ * @since 3.4.0
+ * @see #systemPropertyVariables
+ */
+@Parameter(defaultValue = "true")
+boolean useUserPropertiesAsSystemProperty;
Review Comment:
yes, maybe or `promoteUserPropertiesToSystemProperties`. The term "promote"
we use in Maven Core as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1385) System properties defined in the Surefire and Failsafe plugin configuration should override user properties
[
https://issues.apache.org/jira/browse/SUREFIRE-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868184#comment-17868184
]
ASF GitHub Bot commented on SUREFIRE-1385:
--
michael-o commented on code in PR #762:
URL: https://github.com/apache/maven-surefire/pull/762#discussion_r1688680611
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java:
##
@@ -319,25 +320,44 @@ public abstract class AbstractSurefireMojo extends
AbstractMojo implements Suref
*/
@Deprecated
@Parameter
-private Properties systemProperties;
+Properties systemProperties;
/**
* List of System properties to pass to a provider.
* The effective system properties given to a provider are contributed
from several sources:
*
+ * properties set via {@link #argLine} with {@code -D} (only for
forked executions)
* {@link #systemProperties}
* {@link AbstractSurefireMojo#getSystemPropertiesFile()} (set via
parameter {@code systemPropertiesFile} on some goals)
* {@link #systemPropertyVariables}
- * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D}
+ * User properties from {@link MavenSession#getUserProperties()},
usually set via CLI options given with {@code -D} on the current Maven process
(only used as source if {@link #useUserPropertiesAsSystemProperty} is {@code
true})
*
* Later sources may overwrite same named properties from earlier sources,
that means for example that one cannot overwrite user properties with either
- * {@link #systemProperties}, {@link
AbstractSurefireMojo#getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ * {@link #systemProperties}, {@link #getSystemPropertiesFile()} or {@link
#systemPropertyVariables}.
+ *
+ * Certain properties may only be overwritten via {@link #argLine}
(applicable only for forked executions) because their values are cached and
only evaluated at the start of the JRE.
+ * Those include:
+ *
+ * {@code java.library.path}
+ * {@code file.encoding}
+ * {@code jdk.map.althashing.threshold}
+ * {@code line.separator}
+ *
*
* @since 2.5
* @see #systemProperties
*/
@Parameter
-private Map systemPropertyVariables;
+Map systemPropertyVariables;
+
+/**
+ * If set to {@code true} will also pass all user properties exposed via
{@link MavenSession#getUserProperties()} as system properties to a provider.
+ * Those always take precedence over same named system properties set via
any other means.
+ * @since 3.4.0
+ * @see #systemPropertyVariables
+ */
+@Parameter(defaultValue = "true")
+boolean useUserPropertiesAsSystemProperty;
Review Comment:
yes, maybe or `promoteUserPropertiesToSystemProperties`. The term "promote"
we use in Maven Core as well.
> System properties defined in the Surefire and Failsafe plugin configuration
> should override user properties
> ---
>
> Key: SUREFIRE-1385
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1385
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: Guillaume Boué
>Assignee: Konrad Windszus
>Priority: Major
>
> Consider a build with the following POM configuration for the Maven Failsafe
> Plugin:
> {code:xml}
>
>
> foo
>
>
> {code}
> When running the build with the command line {{mvn -Dprop=bar ...}}, the
> tests would be passed a system property with a value of {{bar}} instead of
> {{foo}}.
> This is counter-intuitive since direct configuration of the plugin is
> overriden by the more general properties passed on the command line. I would
> have expected the closer definition in the POM to override the one passed
> with the CLI. Furthermore, in the case of the above sample, it would not be
> possible for the tests run by the Failsafe Plugin to have a system property
> {{prop}} with a value of {{foo}} if the build happens to already define a
> system property with the same name. While using a different name to avoid a
> clash is possible, it still doesn't make the test self-contained and
> consistent since anyone could run Maven with that other name and compromise
> the test that really relies on the system property having a value of {{foo}}.
> The proposal is thus to make the {{systemPropertyVariables}} and
> {{systemPropertiesFile}} configuration elements of the Surefire and Failsafe
> Plugin take precedence over user properties passed on the command line.
> Proposed commit
> [4de017b38b101b0b
[jira] [Created] (MGPG-129) sign-and-deploy-file incorrectly renames source files when deployed.
Lee Rhodes created MGPG-129: --- Summary: sign-and-deploy-file incorrectly renames source files when deployed. Key: MGPG-129 URL: https://issues.apache.org/jira/browse/MGPG-129 Project: Maven GPG Plugin Issue Type: Bug Affects Versions: 3.2.4, 3.2.3, 3.0.1 Environment: MacOS 14.5, using bash scripts to call maven. Reporter: Lee Rhodes Attachments: Debug_output.txt, package-multi-release-jar.sh, pom.xml, sign-deploy-jar.sh "sign-and-deploy-file" does not just sign and deploy the given source files, it is also renaming them, which causes the deployed files to have incorrect names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MGPG-129) sign-and-deploy-file incorrectly renames source files when deployed.
[ https://issues.apache.org/jira/browse/MGPG-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lee Rhodes updated MGPG-129: Docs Text: You can see from the Debug_output.txt (line 209) that the source files are of the form: "datasketches-memory-3.0.0.jar", "datasketches-memory-3.0.0-tests.jar", etc. But the files being deployed (line 252) are of the form: "datasketches-memory-root-3.0.0.jar", etc. This extra "-root" is incorrect. How do I fix this so that the given files are just signed and deployed without being renamed? This can be replicated from the open-source site: https://github.com/apache/datasketches-memory/tree/3.0.X. First run the "package-multi-release-jar.sh", which creates the source files under /target/. Then run the script "sign-deploy-jar.sh" with inputs "3.0.0" . You will need an account on Nexus. BTW, the source file names have to be different from the root project name because the source files are MR-Jars that have been assembled by the above "package-multi-release-jar.sh". was: You can see from the Debug_output.txt (line 209) that the source files are of the form: "datasketches-memory-3.0.0.jar", "datasketches-memory-3.0.0-tests.jar", etc. But the files being deployed (line 252) are of the form: "datasketches-memory-root-3.0.0.jar", etc. This extra "-root" is incorrect. How do I fix this so that the given files are just signed and deployed without being renamed? This can be replicated from the open-source site: https://github.com/apache/datasketches-memory/tree/3.0.X and running the above script "sign-deploy-jar.sh" with inputs "3.0.0" . You will need an account on Nexus. BTW, the source file names have to be different from the root project name because the source files are MR-Jars that have been assembled by the above "package-multi-release-jar.sh". > sign-and-deploy-file incorrectly renames source files when deployed. > > > Key: MGPG-129 > URL: https://issues.apache.org/jira/browse/MGPG-129 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.0.1, 3.2.3, 3.2.4 > Environment: MacOS 14.5, using bash scripts to call maven. >Reporter: Lee Rhodes >Priority: Major > Attachments: Debug_output.txt, package-multi-release-jar.sh, pom.xml, > sign-deploy-jar.sh > > > "sign-and-deploy-file" does not just sign and deploy the given source files, > it is also renaming them, which causes the deployed files to have incorrect > names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump org.apache.bcel:bcel from 6.9.0 to 6.10.0 [maven-shared-jar]
dependabot[bot] opened a new pull request, #46: URL: https://github.com/apache/maven-shared-jar/pull/46 Bumps [org.apache.bcel:bcel](https://github.com/apache/commons-bcel) from 6.9.0 to 6.10.0. Changelog Sourced from https://github.com/apache/commons-bcel/blob/master/RELEASE-NOTES.txt";>org.apache.bcel:bcel's changelog. Apache Commons BCEL Version 6.10.0 RELEASE NOTES Introduction The Apache Commons BCEL team is pleased to announce the release of Apache Commons BCEL 6.10.0. The Byte Code Engineering Library (BCEL) is intended to give users a convenient way to analyze, create, and manipulate compiled .class files. Classes are represented by objects containing all the symbolic information of the given class: methods, fields, and byte code instructions. Maintenance and bug fix release. Requires a minimum of Java 8. Changes Fix PMD UnnecessaryFullyQualifiedName. Thanks to Gary Gregory. Fix PMD EmptyCatchBlock by allowing commented blocks. Thanks to Gary Gregory. Fix PMD EmptyControlStatement by allowing commented blocks. Thanks to Gary Gregory. Fix SpotBugs RV_RETURN_VALUE_IGNORED_BAD_PRACTICE in JasminVisitor. Thanks to Gary Gregory. SpotBugs checks should ignore code generated by JavaCC. Thanks to Gary Gregory. Fix SpotBugs URF_UNREAD_FIELD in ClassDumper. Thanks to Gary Gregory. Fix SpotBugs DM_DEFAULT_ENCODING in JasminVisitor. Thanks to Gary Gregory. Fix SpotBugs RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE in ASTFunAppl. Thanks to Gary Gregory. Fix SpotBugs RV_ABSOLUTE_VALUE_OF_HASHCODE in Mini.Environment. Thanks to Gary Gregory. Fix SpotBugs DM_DEFAULT_ENCODING in Mini.MiniC. Thanks to Gary Gregory. Fix SpotBugs WMI_WRONG_MAP_ITERATOR in Package.go(String[]). Thanks to Gary Gregory. Deprecate TransitiveHull.INGORED in favor of TransitiveHull.getIgnored(). Thanks to Gary Gregory. Add accessors to model and unit tests, Javadoc [#183](https://github.com/apache/commons-bcel/issues/183). Thanks to nbauma109, Gary Gregory, Mark Roberts. Add Const.MAJOR_22. Thanks to Gary Gregory. Add Const.MINOR_22. Thanks to Gary Gregory. Add Const.MAJOR_23. Thanks to Gary Gregory. Add Const.MINOR_23. Thanks to Gary Gregory. Add Const.MAJOR_24. Thanks to Gary Gregory. Add Const.MINOR_24. Thanks to Gary Gregory. Bump tests from org.assertj:assertj-core 3.25.3 to 3.26.3 [#322](https://github.com/apache/commons-bcel/issues/322), [#332](https://github.com/apache/commons-bcel/issues/332). Thanks to Dependabot. Bump tests from org.jetbrains.kotlin:kotlin-stdlib 1.9.23 to 2.0.0 [#309](https://github.com/apache/commons-bcel/issues/309), [#318](https://github.com/apache/commons-bcel/issues/318). Thanks to Dependabot. Bump tests from org.apache.commons:commons-collections4 4.4 to 4.5.0-M2. Thanks to Gary Gregory. Bump org.apache.commons:commons-parent from 69 to 71. Thanks to Gary Gregory. Bump org.codehaus.mojo:taglist-maven-plugin from 3.0.0 to 3.1.0 [#331](https://github.com/apache/commons-bcel/issues/331). Thanks to Gary Gregory. Historical list of changes: https://commons.apache.org/proper/commons-bcel/changes-report.html";>https://commons.apache.org/proper/commons-bcel/changes-report.html For complete information on Apache Commons BCEL, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons BCEL website: https://commons.apache.org/proper/commons-bcel";>https://commons.apache.org/proper/commons-bcel ... (truncated) Commits https://github.com/apache/commons-bcel/commit/907c61da34258b8ab70081056443818312e404f6";>907c61d Prepare for the next release candidate https://github.com/apache/commons-bcel/commit/a7333c089bd27d87fc472eebb6ee9cbb58218f47";>a7333c0 Prepare for the next release candidate https://github.com/apache/commons-bcel/commit/2d95820fa2a34f6a38edfb9f838195c68b39f6c0";>2d95820 Add Const.MAJOR_24 https://github.com/apache/commons-bcel/commit/8f87b819d3b00831b1e62ac2659dfeb7bc9a0897";>8f87b81 Add Const.MAJOR_23 https://github.com/apache/commons-bcel/commit/e9aa06834d3b654713df056a84d4ef008227f7b9";>e9aa068 Add Const.MAJOR_22 https://github.com/apache/commons-bcel/commit/9818c8929c9c3e85f85e1518d4d74bed9d245e50";>9818c89 Bump org.assertj:assertj-core from 3.26.0 to 3.26.3 https://redirect.github.com/apache/commons-bcel/issues/332";>#332 https://github.com/apache/commons-bcel/commit/10f5191069d88e28d5a08652e315c15bdfd
[jira] [Updated] (MGPG-129) sign-and-deploy-file incorrectly renames source files when deployed.
[ https://issues.apache.org/jira/browse/MGPG-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MGPG-129: Docs Text: (was: You can see from the Debug_output.txt (line 209) that the source files are of the form: "datasketches-memory-3.0.0.jar", "datasketches-memory-3.0.0-tests.jar", etc. But the files being deployed (line 252) are of the form: "datasketches-memory-root-3.0.0.jar", etc. This extra "-root" is incorrect. How do I fix this so that the given files are just signed and deployed without being renamed? This can be replicated from the open-source site: https://github.com/apache/datasketches-memory/tree/3.0.X. First run the "package-multi-release-jar.sh", which creates the source files under /target/. Then run the script "sign-deploy-jar.sh" with inputs "3.0.0" . You will need an account on Nexus. BTW, the source file names have to be different from the root project name because the source files are MR-Jars that have been assembled by the above "package-multi-release-jar.sh". ) > sign-and-deploy-file incorrectly renames source files when deployed. > > > Key: MGPG-129 > URL: https://issues.apache.org/jira/browse/MGPG-129 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.0.1, 3.2.3, 3.2.4 > Environment: MacOS 14.5, using bash scripts to call maven. >Reporter: Lee Rhodes >Priority: Major > Attachments: Debug_output.txt, package-multi-release-jar.sh, pom.xml, > sign-deploy-jar.sh > > > "sign-and-deploy-file" does not just sign and deploy the given source files, > it is also renaming them, which causes the deployed files to have incorrect > names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MGPG-129) sign-and-deploy-file incorrectly renames source files when deployed.
[ https://issues.apache.org/jira/browse/MGPG-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MGPG-129: Description: You can see from the Debug_output.txt (line 209) that the source files are of the form: "datasketches-memory-3.0.0.jar", "datasketches-memory-3.0.0-tests.jar", etc. But the files being deployed (line 252) are of the form: "datasketches-memory-root-3.0.0.jar", etc. This extra "-root" is incorrect. How do I fix this so that the given files are just signed and deployed without being renamed? This can be replicated from the open-source site: https://github.com/apache/datasketches-memory/tree/3.0.X. First run the "package-multi-release-jar.sh", which creates the source files under /target/. Then run the script "sign-deploy-jar.sh" with inputs "3.0.0" . You will need an account on Nexus. BTW, the source file names have to be different from the root project name because the source files are MR-Jars that have been assembled by the above "package-multi-release-jar.sh". "sign-and-deploy-file" does not just sign and deploy the given source files, it is also renaming them, which causes the deployed files to have incorrect names. was:"sign-and-deploy-file" does not just sign and deploy the given source files, it is also renaming them, which causes the deployed files to have incorrect names. > sign-and-deploy-file incorrectly renames source files when deployed. > > > Key: MGPG-129 > URL: https://issues.apache.org/jira/browse/MGPG-129 > Project: Maven GPG Plugin > Issue Type: Bug >Affects Versions: 3.0.1, 3.2.3, 3.2.4 > Environment: MacOS 14.5, using bash scripts to call maven. >Reporter: Lee Rhodes >Priority: Major > Attachments: Debug_output.txt, package-multi-release-jar.sh, pom.xml, > sign-deploy-jar.sh > > > You can see from the Debug_output.txt (line 209) that the source files are of > the form: "datasketches-memory-3.0.0.jar", > "datasketches-memory-3.0.0-tests.jar", etc. > But the files being deployed (line 252) are of the form: > "datasketches-memory-root-3.0.0.jar", etc. This extra "-root" is incorrect. > How do I fix this so that the given files are just signed and deployed > without being renamed? > This can be replicated from the open-source site: > https://github.com/apache/datasketches-memory/tree/3.0.X. > First run the "package-multi-release-jar.sh", which creates the source files > under /target/. Then run the script "sign-deploy-jar.sh" with inputs "3.0.0" > . You will need an account on Nexus. > BTW, the source file names have to be different from the root project name > because the source files are MR-Jars that have been assembled by the above > "package-multi-release-jar.sh". > "sign-and-deploy-file" does not just sign and deploy the given source files, > it is also renaming them, which causes the deployed files to have incorrect > names. -- This message was sent by Atlassian Jira (v8.20.10#820010)
