-
Notifications
You must be signed in to change notification settings - Fork 542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SUREFIRE-1385] Add new parameter "userPropertyVariables" to overwrite #762
Conversation
user properties Log overwritten properties Clarify effective properties merging order
865e46d
to
476b18a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you have if we have any documentation in site which needs updating?
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
Outdated
Show resolved
Hide resolved
Will happily review... |
* @see #systemPropertyVariables | ||
*/ | ||
@Parameter | ||
Map<String, String> userPropertyVariables; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From test perspective there are system properties - not a user properties.
Next parameter like this can confusing user and will be used in random.
I would like to consider changing a priority for systemPropertyVariables
,
even more user can take old behavior by settings properties in project and use it in configuration.
Maybe we should don't pass a MavenSession#getUserProperties()
by default to tests ....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to consider changing a priority for systemPropertyVariables,
...
Maybe we should don't pass a MavenSession#getUserProperties() by default to tests ....
Both approaches will potentially trigger backwards compatibility issues for certain edge cases. I don't think we can do that for a 3.x release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any suggestion for another name? As I said above, I don't think we can fix this in a backwards-compatible way without introducing another parameter...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kwin The let's make it right -- after all -- with a deprecated param with retains old behavior. Surefire 4 is far away, this issue has been open for too long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's make it right
What is right? As outlined in https://issues.apache.org/jira/browse/SUREFIRE-1385?focusedCommentId=17864170&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17864170 there is no simple solution IMHO:
The default should still be to allow overwrites with CLI arguments. Overwriting CLI arguments with plugin parameters is the edge case which we need to support on an exceptional base. I don't see a simple solution without adding a param. Please make a proposal what you consider right here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how this helps here. Let us focus on how you think it should work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about a boolean parameter includeUserPropertiesInSystemProperties
which is true
by default (for backwards compatibility). If set to false
this will prevent passing on the user properties to the provider at all. This will make the addition of the userPropertyVariables
parameter obsolete from my perspective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I implemented the aforementioned approach now in f8b0f57.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I will try to dedicate some to it soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@slawekjaranowski I agree with you that passing user properties by default is a bad idea.
the default is true for being backwards compatible
Maybe https://maven.apache.org/surefire/maven-surefire-plugin/examples/system-properties.html, but nothing in it becomes incorrect, but maybe worth to mention there the additional parameter. |
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... |
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
Outdated
Show resolved
Hide resolved
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
Outdated
Show resolved
Hide resolved
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
Outdated
Show resolved
Hide resolved
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
Outdated
Show resolved
Hide resolved
I already extended the javadoc in cd72eaa (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. |
09ec17a
to
1afafc0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One nit, but the rest is fine. At someone else should have a look at this too.
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
Show resolved
Hide resolved
I guess @slawekjaranowski is on vacation. Let's leave him sometime to review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks ok, thanks
user properties
Log overwritten properties
Clarify effective properties merging order
Following this checklist to help us incorporate your
contribution quickly and easily:
for the change (usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue, without
pulling in other changes.
[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles
,where you replace
SUREFIRE-XXX
with the appropriate JIRA issue. Best practiceis to use the JIRA issue title in the pull request title and in the first line of the
commit message.
mvn clean install
to make sure basic checks pass. A more thorough check willbe performed on your pull request automatically.
mvn -Prun-its clean install
).If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.
I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.