[jira] [Commented] (SUREFIRE-1934) Ability to disable system-out/system-err for successfuly passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814663#comment-17814663 ] ASF GitHub Bot commented on SUREFIRE-1934: -- zabetak commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1928963618 > The code contradicts the issue summary. Either one should be picked. Sure that is an obvious problem. It seems though that we all kind of agree with the idea in the code so we could just edit the summary and move this forward. > Ability to disable system-out/system-err for successfuly passed tests > - > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Priority: Major > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-1934] Ability to disable system-out/system-err for successfuly passed tests. [maven-surefire]
zabetak commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1928963618 > The code contradicts the issue summary. Either one should be picked. Sure that is an obvious problem. It seems though that we all kind of agree with the idea in the code so we could just edit the summary and move this forward. -- 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-2234) Test name pattern '*' not recognised when using dot separators
[
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814629#comment-17814629
]
Alexander Kriegisch commented on SUREFIRE-2234:
---
[~stanio], but it does not work with package names as documented, that is the
whole point. And the workaround {code}dev.aspectj.?*{code} is utterly cryptic
and unintuitive. The bug needs to be fixed, and my patch shows one possible way
to do that.
> Test name pattern '*' not recognised when using dot separators
> --
>
> Key: SUREFIRE-2234
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2234
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.2.5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> As discussed in this [users mailing list
> thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
> something like
> {code:none}
> mvn test -Dtest=dev.aspectj.*{code}
> does not work, while
> {code:none}
> mvn test -Dtest=dev/aspectj/*{code}
> does. I.e., the matcher does not treat "/" path separators and "." package
> separators as equivalent, which IMO it should, also in more complex globbing
> patterns like
> {code:none}
> dev.aspectj.**.*{code}
> Interestingly, as soon as there is a prefix to the asterisk, it starts
> working again, e.g.
> {code:none}
> dev.aspectj.MyO*{code}
> _Sorry for using code blocks rather than inline code formatting, but Jira has
> problems with inline asterisk characters outside of code blocks._
> One quick fix that fors for me locally, is
> {code:none}
> ---
> a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
> (revision Staged)
> +++
> b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
> (date 1707188275344)
> @@ -339,7 +339,7 @@
> private boolean matchClassPatter(String testClassFile) {
> // @todo We have to use File.separator only because the
> MatchPatterns is using it internally - cannot
> // override.
> -String classPattern = ResolvedTest.this.classPattern;
> +String classPattern =
> ResolvedTest.this.classPattern.replace('.', '/');
> if (separatorChar != '/') {
> testClassFile = testClassFile.replace('/', separatorChar);
> classPattern = classPattern.replace('/', separatorChar);
> {code}
> I did not thoroughly test it, but at least as a commiter you know where you
> can start looking.
> The reason why this is a patch rather than a PR is that maybe this is the
> wrong place to replace the dots by slashes. Maybe, that should happen much
> earlier when parsing the patterns from the {{test}} parameter for the first
> time, if it is clear that they are no regex patterns. I think, the committers
> here know much better than I.
> P.S.: If you are changing anything in that class, maybe you can take the
> change to correctly rename the two private methods {{matchClassPatter}} and
> {{matchClassRegexPatter}} to end with "n".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2234) Test name pattern '*' not recognised when using dot separators
[
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814625#comment-17814625
]
Stanimir Stamenkov commented on SUREFIRE-2234:
--
{quote}
Interestingly, as soon as there is a prefix to the asterisk, it starts working
again, e.g.
{code:none}dev.aspectj.MyO*{code}
{quote}
I've also tried the following appear to work (around):
{code:none}dev.aspectj.?*{code}
> Test name pattern '*' not recognised when using dot separators
> --
>
> Key: SUREFIRE-2234
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2234
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.2.5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> As discussed in this [users mailing list
> thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
> something like
> {code:none}
> mvn test -Dtest=dev.aspectj.*{code}
> does not work, while
> {code:none}
> mvn test -Dtest=dev/aspectj/*{code}
> does. I.e., the matcher does not treat "/" path separators and "." package
> separators as equivalent, which IMO it should, also in more complex globbing
> patterns like
> {code:none}
> dev.aspectj.**.*{code}
> Interestingly, as soon as there is a prefix to the asterisk, it starts
> working again, e.g.
> {code:none}
> dev.aspectj.MyO*{code}
> _Sorry for using code blocks rather than inline code formatting, but Jira has
> problems with inline asterisk characters outside of code blocks._
> One quick fix that fors for me locally, is
> {code:none}
> ---
> a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
> (revision Staged)
> +++
> b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
> (date 1707188275344)
> @@ -339,7 +339,7 @@
> private boolean matchClassPatter(String testClassFile) {
> // @todo We have to use File.separator only because the
> MatchPatterns is using it internally - cannot
> // override.
> -String classPattern = ResolvedTest.this.classPattern;
> +String classPattern =
> ResolvedTest.this.classPattern.replace('.', '/');
> if (separatorChar != '/') {
> testClassFile = testClassFile.replace('/', separatorChar);
> classPattern = classPattern.replace('/', separatorChar);
> {code}
> I did not thoroughly test it, but at least as a commiter you know where you
> can start looking.
> The reason why this is a patch rather than a PR is that maybe this is the
> wrong place to replace the dots by slashes. Maybe, that should happen much
> earlier when parsing the patterns from the {{test}} parameter for the first
> time, if it is clear that they are no regex patterns. I think, the committers
> here know much better than I.
> P.S.: If you are changing anything in that class, maybe you can take the
> change to correctly rename the two private methods {{matchClassPatter}} and
> {{matchClassRegexPatter}} to end with "n".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2234) Test name pattern '*' not recognised when using dot separators
[
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814621#comment-17814621
]
Stanimir Stamenkov commented on SUREFIRE-2234:
--
Quote from the current [plugin
documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html#fully-qualified-class-name]:
{quote}
*Fully qualified class name*
As of Surefire Plugin 2.19.1, the syntax with fully qualified class names or
packages can be used, e.g.:
{code:xml}
my.package.???Test#testMethod, another.package.*
{code}
{quote}
Notice: _syntax with fully qualified class names *or packages* can be used_,
and the example: {{another.package.*}}
> Test name pattern '*' not recognised when using dot separators
> --
>
> Key: SUREFIRE-2234
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2234
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.2.5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> As discussed in this [users mailing list
> thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
> something like
> {code:none}
> mvn test -Dtest=dev.aspectj.*{code}
> does not work, while
> {code:none}
> mvn test -Dtest=dev/aspectj/*{code}
> does. I.e., the matcher does not treat "/" path separators and "." package
> separators as equivalent, which IMO it should, also in more complex globbing
> patterns like
> {code:none}
> dev.aspectj.**.*{code}
> Interestingly, as soon as there is a prefix to the asterisk, it starts
> working again, e.g.
> {code:none}
> dev.aspectj.MyO*{code}
> _Sorry for using code blocks rather than inline code formatting, but Jira has
> problems with inline asterisk characters outside of code blocks._
> One quick fix that fors for me locally, is
> {code:none}
> ---
> a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
> (revision Staged)
> +++
> b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
> (date 1707188275344)
> @@ -339,7 +339,7 @@
> private boolean matchClassPatter(String testClassFile) {
> // @todo We have to use File.separator only because the
> MatchPatterns is using it internally - cannot
> // override.
> -String classPattern = ResolvedTest.this.classPattern;
> +String classPattern =
> ResolvedTest.this.classPattern.replace('.', '/');
> if (separatorChar != '/') {
> testClassFile = testClassFile.replace('/', separatorChar);
> classPattern = classPattern.replace('/', separatorChar);
> {code}
> I did not thoroughly test it, but at least as a commiter you know where you
> can start looking.
> The reason why this is a patch rather than a PR is that maybe this is the
> wrong place to replace the dots by slashes. Maybe, that should happen much
> earlier when parsing the patterns from the {{test}} parameter for the first
> time, if it is clear that they are no regex patterns. I think, the committers
> here know much better than I.
> P.S.: If you are changing anything in that class, maybe you can take the
> change to correctly rename the two private methods {{matchClassPatter}} and
> {{matchClassRegexPatter}} to end with "n".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Priority: Major (was: Minor)
> JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
> ---
>
> Key: SUREFIRE-2147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2147
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M7, 3.2.5
>Reporter: Geoff Soutter
>Priority: Major
>
> h3. Description of the issue
> I created a simple example of JUnit5 DynamicContainer/DynamicTest
> {code:java}
> package pkg;
> import ...
> public class JUnit5DynamicTest {
> @TestFactory
> Collection createDynamicTests() {
> List folder2 = new ArrayList<>();
> folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
> folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
> List folder1 = new ArrayList<>();
> folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
> List rootFolder = new ArrayList<>();
> rootFolder.add(DynamicContainer.dynamicContainer("folder1", folder1));
> return rootFolder;
> }
> private static class MyExecutable implements Executable {
> @Override
> public void execute() throws Throwable {
> }
> }
> }
> {code}
> When I run this in IDEA. I get the following hierarchical structure in the UI
> treeview
> * JUnit5DynamicTest (pkg)
> ** createDynamicTests()
> *** folder1
> folder2
> * test1
> * test2
> Here we can see that dynamic tests are represented by IDEA as nested children
> of the test method. We can open and close the "virtual packages" created as
> usual to explore in the dynamically created test results. It is not a "flat
> list".
> Using surefire 3.2.5 and JUnit5Xml30StatelessReporter, with the "phrased"
> reported configuration disabled, it creates content in surefire-reports like
> so
> {code}
>time="0.012"/>
>time="0.001"/>
> {code}
> In this case the Dynamic Tests are completely obscured, instead we get
> duplicate reports for the @TestFactory method.
> With the example "phrased" reporter configuration "use" properties enabled,
> we get
> {code:java}
>classname="pkg.JUnit5DynamicTest" time="0.011"/>
>classname="pkg.JUnit5DynamicTest" time="0.001"/>
> {code}
> Here all the Dynamic tests are created as synthetic "methods" of the physical
> class in the HTML report, with the DynamicContainer and DynamicTest names
> injected into the phrased "method" name.
> From the perspective of someone with a lot of dynamic tests in a huge folder
> structure, this is less than ideal as the nested structure is not exposed in
> the test report in a clean structure way, as it was with package names.
> So how do the tools that process this XML into HTML reports handle it?
> * should we be forced to enable phrased naming so that reporting tools can
> access the dynamic folder and test names?
> * assuming the above is true, how can reporting tools show the nested
> structure of the DynamicFolders? Should they parse the phrased method name to
> find the individual components?
> Also the internal ordering seems inconsistent, or at least I don't understand
> the structure. surely folder1 should come before folder2 If we expect the
> ordering defined by heirarchy position then we would expect the folder/method
> names like "createDynamicTest() folder1 folder2 test1".
> h3. Solution Ideas
> We have two ways to look at this, using non phrased method names, or phrased
> method names.
> h3. Non Phrased
> Dynamic tests with non phrased method names are currently not usable. So
> anything we do here would be an improvement.
> So for non phrased method names, we could add the dynamic names as synthetic
> child packages in the classname attribute.
> That is, when mapping from DynamicTests to Java packages, we have:
> || Java Structure || Dynamic Test Structure ||
> | package identifier | DynamicContainer name |
> | class name | static placeholder (e.g. Tests) |
> | method name | DynamicTest name |
>
> I think we could do that by moving the method name and folder name from name=
> into classname= and adding a static placeholder for the classname.
> {code:java}
>classname="pkg.JUnit5DynamicTest.createDynamicTests().folder1.folder2.Tests"/>
>classname="pkg.JUnit5DynamicTest.createDynamicTests().folder1.folder2.Tests"/>
> {code}
> h3. Phrased
> For phrased usage, its less obvious what to do.
> The nested structure is injected into a single XML attribute and I haven't
> seen any documentation of the internal structure of that attribute.
> The ordering looks inconsistent as it is and possibly needs fixing. However,
> changing
[jira] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Priority: Minor (was: Major)
> JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
> ---
>
> Key: SUREFIRE-2147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2147
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M7, 3.2.5
>Reporter: Geoff Soutter
>Priority: Minor
>
> h3. Description of the issue
> I created a simple example of JUnit5 DynamicContainer/DynamicTest
> {code:java}
> package pkg;
> import ...
> public class JUnit5DynamicTest {
> @TestFactory
> Collection createDynamicTests() {
> List folder2 = new ArrayList<>();
> folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
> folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
> List folder1 = new ArrayList<>();
> folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
> List rootFolder = new ArrayList<>();
> rootFolder.add(DynamicContainer.dynamicContainer("folder1", folder1));
> return rootFolder;
> }
> private static class MyExecutable implements Executable {
> @Override
> public void execute() throws Throwable {
> }
> }
> }
> {code}
> When I run this in IDEA. I get the following hierarchical structure in the UI
> treeview
> * JUnit5DynamicTest (pkg)
> ** createDynamicTests()
> *** folder1
> folder2
> * test1
> * test2
> Here we can see that dynamic tests are represented by IDEA as nested children
> of the test method. We can open and close the "virtual packages" created as
> usual to explore in the dynamically created test results. It is not a "flat
> list".
> Using surefire 3.2.5 and JUnit5Xml30StatelessReporter, with the "phrased"
> reported configuration disabled, it creates content in surefire-reports like
> so
> {code}
>time="0.012"/>
>time="0.001"/>
> {code}
> In this case the Dynamic Tests are completely obscured, instead we get
> duplicate reports for the @TestFactory method.
> With the example "phrased" reporter configuration "use" properties enabled,
> we get
> {code:java}
>classname="pkg.JUnit5DynamicTest" time="0.011"/>
>classname="pkg.JUnit5DynamicTest" time="0.001"/>
> {code}
> Here all the Dynamic tests are created as synthetic "methods" of the physical
> class in the HTML report, with the DynamicContainer and DynamicTest names
> injected into the phrased "method" name.
> From the perspective of someone with a lot of dynamic tests in a huge folder
> structure, this is less than ideal as the nested structure is not exposed in
> the test report in a clean structure way, as it was with package names.
> So how do the tools that process this XML into HTML reports handle it?
> * should we be forced to enable phrased naming so that reporting tools can
> access the dynamic folder and test names?
> * assuming the above is true, how can reporting tools show the nested
> structure of the DynamicFolders? Should they parse the phrased method name to
> find the individual components?
> Also the internal ordering seems inconsistent, or at least I don't understand
> the structure. surely folder1 should come before folder2 If we expect the
> ordering defined by heirarchy position then we would expect the folder/method
> names like "createDynamicTest() folder1 folder2 test1".
> h3. Solution Ideas
> We have two ways to look at this, using non phrased method names, or phrased
> method names.
> h3. Non Phrased
> Dynamic tests with non phrased method names are currently not usable. So
> anything we do here would be an improvement.
> So for non phrased method names, we could add the dynamic names as synthetic
> child packages in the classname attribute.
> That is, when mapping from DynamicTests to Java packages, we have:
> || Java Structure || Dynamic Test Structure ||
> | package identifier | DynamicContainer name |
> | class name | static placeholder (e.g. Tests) |
> | method name | DynamicTest name |
>
> I think we could do that by moving the method name and folder name from name=
> into classname= and adding a static placeholder for the classname.
> {code:java}
>classname="pkg.JUnit5DynamicTest.createDynamicTests().folder1.folder2.Tests"/>
>classname="pkg.JUnit5DynamicTest.createDynamicTests().folder1.folder2.Tests"/>
> {code}
> h3. Phrased
> For phrased usage, its less obvious what to do.
> The nested structure is injected into a single XML attribute and I haven't
> seen any documentation of the internal structure of that attribute.
> The ordering looks inconsistent as it is and possibly needs fixing. However,
> changing
[jira] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Affects Version/s: 3.2.5
> JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
> ---
>
> Key: SUREFIRE-2147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2147
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M7, 3.2.5
>Reporter: Geoff Soutter
>Priority: Major
>
> h3. Description of the issue
> I created a simple example of JUnit5 DynamicContainer/DynamicTest
> {code:java}
> package pkg;
> import ...
> public class JUnit5DynamicTest {
> @TestFactory
> Collection createDynamicTests() {
> List folder2 = new ArrayList<>();
> folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
> folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
> List folder1 = new ArrayList<>();
> folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
> List rootFolder = new ArrayList<>();
> rootFolder.add(DynamicContainer.dynamicContainer("folder1", folder1));
> return rootFolder;
> }
> private static class MyExecutable implements Executable {
> @Override
> public void execute() throws Throwable {
> }
> }
> }
> {code}
> When I run this in IDEA. I get the following hierarchical structure in the UI
> treeview
> * JUnit5DynamicTest (pkg)
> ** createDynamicTests()
> *** folder1
> folder2
> * test1
> * test2
> Here we can see that dynamic tests are represented by IDEA as nested children
> of the test method. We can open and close the "virtual packages" created as
> usual to explore in the dynamically created test results. It is not a "flat
> list".
> Using surefire 3.2.5 and JUnit5Xml30StatelessReporter, with the "phrased"
> reported configuration disabled, it creates content in surefire-reports like
> so
> {code}
>time="0.012"/>
>time="0.001"/>
> {code}
> In this case the Dynamic Tests are completely obscured, instead we get
> duplicate reports for the @TestFactory method.
> With the example "phrased" reporter configuration "use" properties enabled,
> we get
> {code:java}
>classname="pkg.JUnit5DynamicTest" time="0.011"/>
>classname="pkg.JUnit5DynamicTest" time="0.001"/>
> {code}
> Here all the Dynamic tests are created as synthetic "methods" of the physical
> class in the HTML report, with the DynamicContainer and DynamicTest names
> injected into the phrased "method" name.
> From the perspective of someone with a lot of dynamic tests in a huge folder
> structure, this is less than ideal as the nested structure is not exposed in
> the test report in a clean structure way, as it was with package names.
> So how do the tools that process this XML into HTML reports handle it?
> * should we be forced to enable phrased naming so that reporting tools can
> access the dynamic folder and test names?
> * assuming the above is true, how can reporting tools show the nested
> structure of the DynamicFolders? Should they parse the phrased method name to
> find the individual components?
> Also the internal ordering seems inconsistent, or at least I don't understand
> the structure. surely folder1 should come before folder2 If we expect the
> ordering defined by heirarchy position then we would expect the folder/method
> names like "createDynamicTest() folder1 folder2 test1".
> h3. Solution Ideas
> We have two ways to look at this, using non phrased method names, or phrased
> method names.
> h3. Non Phrased
> Dynamic tests with non phrased method names are currently not usable. So
> anything we do here would be an improvement.
> So for non phrased method names, we could add the dynamic names as synthetic
> child packages in the classname attribute.
> That is, when mapping from DynamicTests to Java packages, we have:
> || Java Structure || Dynamic Test Structure ||
> | package identifier | DynamicContainer name |
> | class name | static placeholder (e.g. Tests) |
> | method name | DynamicTest name |
>
> I think we could do that by moving the method name and folder name from name=
> into classname= and adding a static placeholder for the classname.
> {code:java}
>classname="pkg.JUnit5DynamicTest.createDynamicTests().folder1.folder2.Tests"/>
>classname="pkg.JUnit5DynamicTest.createDynamicTests().folder1.folder2.Tests"/>
> {code}
> h3. Phrased
> For phrased usage, its less obvious what to do.
> The nested structure is injected into a single XML attribute and I haven't
> seen any documentation of the internal structure of that attribute.
> The ordering looks inconsistent as it is and possibly needs fixing. However,
> changing this
[jira] [Updated] (SUREFIRE-2234) Test name pattern '*' not recognised when using dot separators
[
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kriegisch updated SUREFIRE-2234:
--
Description:
As discussed in this [users mailing list
thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
something like
{code:none}
mvn test -Dtest=dev.aspectj.*{code}
does not work, while
{code:none}
mvn test -Dtest=dev/aspectj/*{code}
does. I.e., the matcher does not treat "/" path separators and "." package
separators as equivalent, which IMO it should, also in more complex globbing
patterns like
{code:none}
dev.aspectj.**.*{code}
Interestingly, as soon as there is a prefix to the asterisk, it starts working
again, e.g.
{code:none}
dev.aspectj.MyO*{code}
_Sorry for using code blocks rather than inline code formatting, but Jira has
problems with inline asterisk characters outside of code blocks._
One quick fix that fors for me locally, is
{code:none}
---
a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(revision Staged)
+++
b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(date 1707188275344)
@@ -339,7 +339,7 @@
private boolean matchClassPatter(String testClassFile) {
// @todo We have to use File.separator only because the
MatchPatterns is using it internally - cannot
// override.
-String classPattern = ResolvedTest.this.classPattern;
+String classPattern = ResolvedTest.this.classPattern.replace('.',
'/');
if (separatorChar != '/') {
testClassFile = testClassFile.replace('/', separatorChar);
classPattern = classPattern.replace('/', separatorChar);
{code}
I did not thoroughly test it, but at least as a commiter you know where you can
start looking.
The reason why this is a patch rather than a PR is that maybe this is the wrong
place to replace the dots by slashes. Maybe, that should happen much earlier
when parsing the patterns from the {{test}} parameter for the first time, if it
is clear that they are no regex patterns. I think, the committers here know
much better than I.
P.S.: If you are changing anything in that class, maybe you can take the change
to correctly rename the two private methods {{matchClassPatter}} and
{{matchClassRegexPatter}} to end with "n".
was:
As discussed in this [users mailing list
thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
something like
{code:none}
mvn test -Dtest=dev.aspectj.*{code}
does not work, while
{code:none}
mvn test -Dtest=dev/aspectj/*{code}
does. I.e., the matcher does not treat "/" path separators and "." package
separators as equivalent, which IMO it should, also in more complex globbing
patterns like
{code:none}
dev.aspectj.**.*{code}
Interestingly, as soon as there is a prefix to the asterisk, it starts working
again, e.g.
{code:none}
dev.aspectj.MyO*{code}
_Sorry for using code blocks rather than inline code formatting, but Jira has
problems with inline asterisk characters outside of code blocks._
One quick fix that fors for me locally, is
{code:none}
---
a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(revision Staged)
+++
b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(date 1707188275344)
@@ -339,7 +339,7 @@
private boolean matchClassPatter(String testClassFile) {
// @todo We have to use File.separator only because the
MatchPatterns is using it internally - cannot
// override.
-String classPattern = ResolvedTest.this.classPattern;
+String classPattern = ResolvedTest.this.classPattern.replace('.',
'/');
if (separatorChar != '/') {
testClassFile = testClassFile.replace('/', separatorChar);
classPattern = classPattern.replace('/', separatorChar);
{code}
I did not thoroughly test it, but at least as a commiter you know where you can
start looking.
The reason why this is a patch rather than a PR is that maybe this is the wrong
place to replace the dots by slashes. Maybe, that should happen much earlier
when parsing the patterns from the {{test}} parameter for the first time, if it
is clear that they are no regex patterns. I think, the committers here know
much better than I.
> Test name pattern '*' not recognised when using dot separators
> --
>
> Key: SUREFIRE-2234
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2234
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.2.5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> As discussed in
[jira] [Updated] (SUREFIRE-2234) Test name pattern '*' not recognised when using dot separators
[
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kriegisch updated SUREFIRE-2234:
--
Description:
As discussed in this [users mailing list
thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
something like
{code:none}
mvn test -Dtest=dev.aspectj.*{code}
does not work, while
{code:none}
mvn test -Dtest=dev/aspectj/*{code}
does. I.e., the matcher does not treat "/" path separators and "." package
separators as equivalent, which IMO it should, also in more complex globbing
patterns like
{code:none}
dev.aspectj.**.*{code}
Interestingly, as soon as there is a prefix to the asterisk, it starts working
again, e.g.
{code:none}
dev.aspectj.MyO*{code}
_Sorry for using code blocks rather than inline code formatting, but Jira has
problems with inline asterisk characters outside of code blocks._
One quick fix that fors for me locally, is
{code:none}
---
a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(revision Staged)
+++
b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(date 1707188275344)
@@ -339,7 +339,7 @@
private boolean matchClassPatter(String testClassFile) {
// @todo We have to use File.separator only because the
MatchPatterns is using it internally - cannot
// override.
-String classPattern = ResolvedTest.this.classPattern;
+String classPattern = ResolvedTest.this.classPattern.replace('.',
'/');
if (separatorChar != '/') {
testClassFile = testClassFile.replace('/', separatorChar);
classPattern = classPattern.replace('/', separatorChar);
{code}
I did not thoroughly test it, but at least as a commiter you know where you can
start looking.
The reason why this is a patch rather than a PR is that maybe this is the wrong
place to replace the dots by slashes. Maybe, that should happen much earlier
when parsing the patterns from the {{test}} parameter for the first time, if it
is clear that they are no regex patterns. I think, the committers here know
much better than I.
was:
As discussed in this [users mailing list
thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
something like
{code:none}mvn test -Dtest=dev.aspectj.*{code}
does not work, while
{code:none}mvn test -Dtest=dev/aspectj/*{code}
does. I.e., the matcher does not treat "/" path separators and "." package
separators as equivalent, which IMO it should, also in more complex globbing
patterns like
{code:none}dev.aspectj.**.*{code}
Interestingly, as soon as there is a prefix to the asterisk, it starts working
again, e.g.
{code:none}dev.aspectj.MyO*{code}
_Sorry for using code blocks rather than inline code formatting, but Jira has
problems with inline asterisk characters outside of code blocks._
One quick fix that fors for me locally, is
{code:none}
---
a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(revision Staged)
+++
b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(date 1707188275344)
@@ -339,7 +339,7 @@
private boolean matchClassPatter(String testClassFile) {
// @todo We have to use File.separator only because the
MatchPatterns is using it internally - cannot
// override.
-String classPattern = ResolvedTest.this.classPattern;
+String classPattern = ResolvedTest.this.classPattern.replace('.',
'/');
if (separatorChar != '/') {
testClassFile = testClassFile.replace('/', separatorChar);
classPattern = classPattern.replace('/', separatorChar);
{code}
I did not thoroughly test it, but at least as a commiter you know where you can
start looking.
> Test name pattern '*' not recognised when using dot separators
> --
>
> Key: SUREFIRE-2234
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2234
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.2.5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> As discussed in this [users mailing list
> thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
> something like
> {code:none}
> mvn test -Dtest=dev.aspectj.*{code}
> does not work, while
> {code:none}
> mvn test -Dtest=dev/aspectj/*{code}
> does. I.e., the matcher does not treat "/" path separators and "." package
> separators as equivalent, which IMO it should, also in more complex globbing
> patterns like
> {code:none}
> dev.aspectj.**.*{code}
> Interestingly, as soon as there is a prefix to the asterisk, it starts
>
[jira] [Updated] (SUREFIRE-2234) Test name pattern '*' not recognised when using dot separators
[
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kriegisch updated SUREFIRE-2234:
--
Description:
As discussed in this [users mailing list
thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
something like
{code:none}mvn test -Dtest=dev.aspectj.*{code}
does not work, while
{code:none}mvn test -Dtest=dev/aspectj/*{code}
does. I.e., the matcher does not treat "/" path separators and "." package
separators as equivalent, which IMO it should, also in more complex globbing
patterns like
{code:none}dev.aspectj.**.*{code}
Interestingly, as soon as there is a prefix to the asterisk, it starts working
again, e.g.
{code:none}dev.aspectj.MyO*{code}
_Sorry for using code blocks rather than inline code formatting, but Jira has
problems with inline asterisk characters outside of code blocks._
One quick fix that fors for me locally, is
{code:none}
---
a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(revision Staged)
+++
b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(date 1707188275344)
@@ -339,7 +339,7 @@
private boolean matchClassPatter(String testClassFile) {
// @todo We have to use File.separator only because the
MatchPatterns is using it internally - cannot
// override.
-String classPattern = ResolvedTest.this.classPattern;
+String classPattern = ResolvedTest.this.classPattern.replace('.',
'/');
if (separatorChar != '/') {
testClassFile = testClassFile.replace('/', separatorChar);
classPattern = classPattern.replace('/', separatorChar);
{code}
I did not thoroughly test it, but at least as a commiter you know where you can
start looking.
was:
As discussed in this [users mailing list
thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
something like {{mvn test -Dtest=dev.aspectj.*}} does not work, while {{mvn
test -Dtest=dev/aspectj/*}} does. I.e., the matcher does not treat "/" path
separators and "." package separators as equivalent, which IMO it should, also
in more complex globbing patterns like {{dev.aspectj.**.*}}. Interestingly, as
soon as there is a prefix to "*", it starts working again, e.g.
{{dev.aspectj.MyO*}}.
One quick fix that fors for me locally, is
{code:none}
---
a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(revision Staged)
+++
b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(date 1707188275344)
@@ -339,7 +339,7 @@
private boolean matchClassPatter(String testClassFile) {
// @todo We have to use File.separator only because the
MatchPatterns is using it internally - cannot
// override.
-String classPattern = ResolvedTest.this.classPattern;
+String classPattern = ResolvedTest.this.classPattern.replace('.',
'/');
if (separatorChar != '/') {
testClassFile = testClassFile.replace('/', separatorChar);
classPattern = classPattern.replace('/', separatorChar);
{code}
I did not thoroughly test it, but at least as a commiter you know where you can
start looking.
> Test name pattern '*' not recognised when using dot separators
> --
>
> Key: SUREFIRE-2234
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2234
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.2.5
>Reporter: Alexander Kriegisch
>Priority: Major
>
> As discussed in this [users mailing list
> thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
> something like
> {code:none}mvn test -Dtest=dev.aspectj.*{code}
> does not work, while
> {code:none}mvn test -Dtest=dev/aspectj/*{code}
> does. I.e., the matcher does not treat "/" path separators and "." package
> separators as equivalent, which IMO it should, also in more complex globbing
> patterns like
> {code:none}dev.aspectj.**.*{code}
> Interestingly, as soon as there is a prefix to the asterisk, it starts
> working again, e.g.
> {code:none}dev.aspectj.MyO*{code}
> _Sorry for using code blocks rather than inline code formatting, but Jira has
> problems with inline asterisk characters outside of code blocks._
> One quick fix that fors for me locally, is
> {code:none}
> ---
> a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
> (revision Staged)
> +++
> b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
> (date 1707188275344)
> @@ -339,7 +339,7 @@
> private
[jira] [Created] (SUREFIRE-2234) Test name pattern '*' not recognised when using dot separators
Alexander Kriegisch created SUREFIRE-2234:
-
Summary: Test name pattern '*' not recognised when using dot
separators
Key: SUREFIRE-2234
URL: https://issues.apache.org/jira/browse/SUREFIRE-2234
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin, Maven Surefire Plugin
Affects Versions: 3.2.5
Reporter: Alexander Kriegisch
As discussed in this [users mailing list
thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl],
something like {{mvn test -Dtest=dev.aspectj.*}} does not work, while {{mvn
test -Dtest=dev/aspectj/*}} does. I.e., the matcher does not treat "/" path
separators and "." package separators as equivalent, which IMO it should, also
in more complex globbing patterns like {{dev.aspectj.**.*}}. Interestingly, as
soon as there is a prefix to "*", it starts working again, e.g.
{{dev.aspectj.MyO*}}.
One quick fix that fors for me locally, is
{code:none}
---
a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(revision Staged)
+++
b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java
(date 1707188275344)
@@ -339,7 +339,7 @@
private boolean matchClassPatter(String testClassFile) {
// @todo We have to use File.separator only because the
MatchPatterns is using it internally - cannot
// override.
-String classPattern = ResolvedTest.this.classPattern;
+String classPattern = ResolvedTest.this.classPattern.replace('.',
'/');
if (separatorChar != '/') {
testClassFile = testClassFile.replace('/', separatorChar);
classPattern = classPattern.replace('/', separatorChar);
{code}
I did not thoroughly test it, but at least as a commiter you know where you can
start looking.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump org.junit:junit-bom from 5.10.1 to 5.10.2 [maven-script-interpreter]
dependabot[bot] merged PR #105: URL: https://github.com/apache/maven-script-interpreter/pull/105 -- 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] Bump org.assertj:assertj-core from 3.25.1 to 3.25.3 [maven-invoker-plugin]
dependabot[bot] merged PR #215: URL: https://github.com/apache/maven-invoker-plugin/pull/215 -- 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] Bump org.apache.groovy:groovy-bom from 4.0.17 to 4.0.18 [maven-invoker-plugin]
olamy merged PR #213: URL: https://github.com/apache/maven-invoker-plugin/pull/213 -- 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] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Description:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List folder1 = new ArrayList<>();
folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
List rootFolder = new ArrayList<>();
rootFolder.add(DynamicContainer.dynamicContainer("folder1", folder1));
return rootFolder;
}
private static class MyExecutable implements Executable {
@Override
public void execute() throws Throwable {
}
}
}
{code}
When I run this in IDEA. I get the following hierarchical structure in the UI
treeview
* JUnit5DynamicTest (pkg)
** createDynamicTests()
*** folder1
folder2
* test1
* test2
Here we can see that dynamic tests are represented by IDEA as nested children
of the test method. We can open and close the "virtual packages" created as
usual to explore in the dynamically created test results. It is not a "flat
list".
Using surefire 3.2.5 and JUnit5Xml30StatelessReporter, with the "phrased"
reported configuration disabled, it creates content in surefire-reports like so
{code}
{code}
In this case the Dynamic Tests are completely obscured, instead we get
duplicate reports for the @TestFactory method.
With the example "phrased" reporter configuration "use" properties enabled, we
get
{code:java}
{code}
Here all the Dynamic tests are created as synthetic "methods" of the physical
class in the HTML report, with the DynamicContainer and DynamicTest names
injected into the phrased "method" name.
>From the perspective of someone with a lot of dynamic tests in a huge folder
>structure, this is less than ideal as the nested structure is not exposed in
>the test report in a clean structure way, as it was with package names.
So how do the tools that process this XML into HTML reports handle it?
* should we be forced to enable phrased naming so that reporting tools can
access the dynamic folder and test names?
* assuming the above is true, how can reporting tools show the nested structure
of the DynamicFolders? Should they parse the phrased method name to find the
individual components?
Also the internal ordering seems inconsistent, or at least I don't understand
the structure. surely folder1 should come before folder2 If we expect the
ordering defined by heirarchy position then we would expect the folder/method
names like "createDynamicTest() folder1 folder2 test1".
h3. Solution Ideas
We have two ways to look at this, using non phrased method names, or phrased
method names.
h3. Non Phrased
Dynamic tests with non phrased method names are currently not usable. So
anything we do here would be an improvement.
So for non phrased method names, we could add the dynamic names as synthetic
child packages in the classname attribute.
That is, when mapping from DynamicTests to Java packages, we have:
|| Java Structure || Dynamic Test Structure ||
| package identifier | DynamicContainer name |
| class name | static placeholder (e.g. Tests) |
| method name | DynamicTest name |
I think we could do that by moving the method name and folder name from name=
into classname= and adding a static placeholder for the classname.
{code:java}
{code}
h3. Phrased
For phrased usage, its less obvious what to do.
The nested structure is injected into a single XML attribute and I haven't seen
any documentation of the internal structure of that attribute.
The ordering looks inconsistent as it is and possibly needs fixing. However,
changing this value without any schema as to what the contents mean seems
dangerous.
Casual testing with an available Jenkins instance seems to indicate that
Jenkins JUnit already has some capability to parse the phrased method name as
it shows folder2 as a "package" (but folder1 is lost).
To get an overall useful result here I guess we'd need to
* create and publish some kind of docs / schema on the internal structure we
want to support for downstream reporting tools
* adjust whatever output we have now to meet the docs/schema, if required
* wait for downstream reporting tools to support it
was:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
[jira] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Description:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List folder1 = new ArrayList<>();
folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
List rootFolder = new ArrayList<>();
rootFolder.add(DynamicContainer.dynamicContainer("folder1", folder1));
return rootFolder;
}
private static class MyExecutable implements Executable {
@Override
public void execute() throws Throwable {
}
}
}
{code}
When I run this in IDEA. I get the following hierarchical structure in the UI
treeview
* JUnit5DynamicTest (pkg)
** createDynamicTests()
*** folder1
folder2
* test1
* test2
Here we can see that dynamic tests are represented by IDEA as nested children
of the test method. We can open and close the "virtual packages" created as
usual to explore in the dynamically created test results. It is not a "flat
list".
Using surefire 3.2.5 and JUnit5Xml30StatelessReporter, with the "phrased"
reported configuration disabled, it creates content in surefire-reports like so
{code}
{code}
In this case the Dynamic Tests are completely obscured, instead we get
duplicate reports for the @TestFactory method.
With the example "phrased" reporter configuration "use" properties enabled, we
get
{code:java}
{code}
Here all the Dynamic tests are created as synthetic "methods" of the physical
class in the HTML report, with the DynamicContainer and DynamicTest names
injected into the phrased "method" name.
>From the perspective of someone with a lot of dynamic tests in a huge folder
>structure, this is less than ideal as the nested structure is not exposed in
>the test report in a clean structure way, as it was with package names.
So how do the tools that process this XML into HTML reports handle it?
* should we be forced to enable phrased naming so that reporting tools can
access the dynamic folder and test names?
* assuming the above is true, how can reporting tools show the nested structure
of the DynamicFolders? Should they parse the phrased method name to find the
individual components?
Also the internal ordering seems inconsistent, if we expect the ordering
defined by heirarchy position then we would expect the folder/method names like
"createDynamicTest() folder1 folder2 test1".
h3. Solution Ideas
We have two ways to look at this, using non phrased method names, or phrased
method names.
h3. Non Phrased
Dynamic tests with non phrased method names are currently not usable. So
anything we do here would be an improvement.
So for non phrased method names, we could add the dynamic names as synthetic
child packages in the classname attribute.
That is, when mapping from DynamicTests to Java packages, we have:
|| Java Structure || Dynamic Test Structure ||
| package identifier | DynamicContainer name |
| class name | static placeholder (e.g. Tests) |
| method name | DynamicTest name |
I think we could do that by moving the method name and folder name from name=
into classname= and adding a static placeholder for the classname.
{code:java}
{code}
h3. Phrased
For phrased usage, its less obvious what to do.
The nested structure is injected into a single XML attribute and I haven't seen
any documentation of the internal structure of that attribute.
The ordering looks inconsistent as it is and possibly needs fixing. However,
changing this value without any schema as to what the contents mean seems to be
dangerous.
Casual testing with an available Jenkins instance seems to indicate that
Jenkins JUnit already has some capability to parse the phrased method name as
it shows folder2 as a "package" (but folder1 is lost).
To get an overall useful result here I guess we'd need to
* create and publish some kind of docs / schema on the internal structure we
want to support for downstream reporting tools
* adjust whatever output we have now to meet the docs/schema, if required
* wait for downstream reporting tools to support it
was:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
[jira] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Description:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List folder1 = new ArrayList<>();
folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
List rootFolder = new ArrayList<>();
rootFolder.add(DynamicContainer.dynamicContainer("folder1", folder1));
return rootFolder;
}
private static class MyExecutable implements Executable {
@Override
public void execute() throws Throwable {
}
}
}
{code}
When I run this in IDEA. I get the following hierarchical structure in the UI
treeview
* JUnit5DynamicTest (pkg)
** createDynamicTests()
*** folder1
folder2
* test1
* test2
Here we can see that dynamic tests are represented by IDEA as nested children
of the test method. We can open and close the "virtual packages" created as
usual to explore in the dynamically created test results. It is not a "flat
list".
Using surefire 3.2.5 and JUnit5Xml30StatelessReporter, with the "phrased"
reported configuration disabled, it creates content in surefire-reports like so
{code}
{code}
In this case the Dynamic Tests are completely obscured, instead we get
duplicate reports for the @TestFactory method.
With the example "phrased" reporter configuration "use" properties enabled, we
get
{code:java}
{code}
Here all the Dynamic tests are created as synthetic "methods" of the physical
class in the HTML report, with the DynamicContainer and DynamicTest names
injected into the phrased "method" name.
>From the perspective of someone with a lot of dynamic tests in a huge folder
>structure, this is less than ideal as the nested structure is not exposed in
>the test report in a clean structure way, as it was with package names.
So how do the tools that process this XML into HTML reports handle it?
* should we be forced to enable phrased naming so that reporting tools can
access the dynamic folder and test names?
* assuming the above is true, how can reporting tools show the nested structure
of the DynamicFolders? Should they parse the phrased method name to find the
individual components?
Also the internal ordering seems inconsistent, if we expect the ordering
defined by heirarchy position then we would expect the folder/method names like
"createDynamicTest() folder1 folder2 test1".
h3. Solution Ideas
We have two ways to look at this, using non phrased method names, or phrased
method names.
h3. Non Phrased
Dynamic tests with non phrased method names are currently not usable. So
anything we do here would be an improvement.
So for non phrased method names, we could add the dynamic names as synthetic
child packages in the classname attribute.
That is, when mapping from DynamicTests to Java packages, we have:
|| Java Structure || Dynamic Test Structure ||
| package identifier | DynamicContainer name |
| class name | static placeholder (e.g. Tests) |
| method name | DynamicTest name |
I think we could do that by moving the method name and folder name from name=
into classname= and adding a static placeholder for the classname.
{code:java}
{code}
h3. Phrased
For phrased usage, its less obvious what to do. The nested structure is
injected into a single XML attribute and I haven't seen any documentation of
the internal structure of that attribute. The ordering looks inconsistent as it
is and possibly needs fixing. However, changing this value without any schema
as to what the contents mean seems to be dangerous.
Casual testing with an available Jenkins instance seems to indicate that
Jenkins JUnit already has some capability to parse the phrased method name as
it shows folder2 as a "package" (but folder1 is lost).
Getting an overall useful result here would mostly rely on fixes in the
downstream reporting tools.
was:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List folder1 = new ArrayList<>();
folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
List rootFolder = new ArrayList<>();
[jira] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Description:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List folder1 = new ArrayList<>();
folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
List rootFolder = new ArrayList<>();
rootFolder.add(DynamicContainer.dynamicContainer("folder1", folder1));
return rootFolder;
}
private static class MyExecutable implements Executable {
@Override
public void execute() throws Throwable {
}
}
}
{code}
When I run this in IDEA. I get the following hierarchical structure in the UI
treeview
* JUnit5DynamicTest (pkg)
** createDynamicTests()
*** folder1
folder2
* test1
* test2
Here we can see that dynamic tests are represented by IDEA as nested children
of the test method. We can open and close the "virtual packages" created as
usual to explore in the dynamically created test results. It is not a "flat
list".
Using surefire 3.2.5 and JUnit5Xml30StatelessReporter, with the "phrased"
reported configuration disabled, it creates content in surefire-reports like so
{code}
{code}
In this case the Dynamic Tests are completely obscured, instead we get
duplicate reports for the @TestFactory method.
With the example "phrased" reporter configuration "use" properties enabled, we
get
{code:java}
{code}
Here all the Dynamic tests are created as synthetic "methods" of the physical
class in the HTML report, with the DynamicContainer and DynamicTest names
injected into the phrased "method" name.
>From the perspective of someone with a lot of dynamic tests in a huge folder
>structure, this is less than ideal as the nested structure is not exposed in
>the test report in a clean structure way, as it was with package names.
So how do the tools that process this XML into HTML reports handle it?
* should we be forced to enable phrased naming so that reporting tools can
access the dynamic folder and test names?
* assuming the above is true, how can reporting tools show the nested structure
of the DynamicFolders? Should they parse the phrased method name to find the
individual components?
Also the internal ordering seems inconsistent, if we expect the ordering
defined by heirarchy position then we would expect the folder/method names like
"createDynamicTest() folder1 folder2 test1".
h3. Solution Ideas
We have two ways to look at this, using non phrased method names, or phrased
method names.
h3. Non Phrased
Dynamic tests with non phrased method names are currently not usable. So
anything we do here would be an improvement.
So for non phrased method names, we could add the dynamic names as synthetic
child packages in the classname attribute.
That is, when mapping from DynamicTests to Java packages, we have:
|| Java Structure || Dynamic Test Structure ||
| package identifier | DynamicContainer name |
| simple class name | static placeholder (e.g. Tests) |
| method name | DynamicTest name |
I think we could do that by moving the method name and folder name from name=
into classname= and adding a static placeholder for the classname.
{code:java}
{code}
h3. Phrased
For phrased usage, its less obvious what to do. The nested structure is
injected into a single XML attribute and I haven't seen any documentation of
the internal structure of that attribute. The ordering looks inconsistent as it
is and possibly needs fixing. However, changing this value without any schema
as to what the contents mean seems to be dangerous.
Casual testing with an available Jenkins instance seems to indicate that
Jenkins JUnit already has some capability to parse the phrased method name as
it shows folder2 as a "package" (but folder1 is lost).
Getting an overall useful result here would mostly rely on fixes in the
downstream reporting tools.
was:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List folder1 = new ArrayList<>();
folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
List rootFolder = new
[jira] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Description:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
import ...
public class JUnit5DynamicTest {
@TestFactory
Collection createDynamicTests() {
List folder2 = new ArrayList<>();
folder2.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
folder2.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List folder1 = new ArrayList<>();
folder1.add(DynamicContainer.dynamicContainer("folder2", folder2));
List rootFolder = new ArrayList<>();
rootFolder.add(DynamicContainer.dynamicContainer("folder1", folder1));
return rootFolder;
}
private static class MyExecutable implements Executable {
@Override
public void execute() throws Throwable {
}
}
}
{code}
When I run this in IDEA. I get the following hierarchical structure in the UI
treeview
* SampleTest (pkg)
** createDynamicTests()
*** folder1
folder2
* test1
* test2
Here we can see that dynamic tests are represented by IDEA as nested children
of the test method. We can open and close the "virtual packages" created as
usual to explore in the dynamically created test results. It is not a "flat
list".
Using surefire 3.2.5 and JUnit5Xml30StatelessReporter, with the "phrased"
reported configuration disabled, it creates content in surefire-reports like so
{code}
{code}
In this case the Dynamic Tests are completely obscured, instead we get
duplicate reports for the @TestFactory method.
With the example "phrased" reporter configuration "use" properties enabled, we
get
{code:java}
{code}
Here all the Dynamic tests are created as synthetic "methods" of the physical
class in the HTML report. The DynamicContainer and DynamicTest names are
injected into the phrased "method" name. Also the internal ordering seems
inconsistent, if we expect the ordering defined by heirarchy position then we
would expect the folder/method names like "createDynamicTest() folder1 folder2
test1".
Problem is how do the tools that process this XML into HTML reports handle it?
* should we enable phrased naming to expose the
This doesn't scale nicely as the number of tests in the dynamically created
"folder" structure grows. We can't view the different DynamicContainers
separately in the rendered HTML reports. We can't get a breakdown on any
particular DynamicContainer in the rendered HTML reports.
h3. Solution Ideas
I think what we want here is that dynamic tests using dynamic containers should
have those container names structured as synthetic packages. This allows us the
benefits of having the nested structure modelled correctly in the HTML report.
That is, when mapping from DynamicTests to Java packages, we have:
|| Java Structure || Dynamic Test Structure ||
| package identifier | DynamicContainer name |
| simple class name | static placeholder (e.g. Tests) |
| method name | DynamicTest name |
I think we could do that by moving the method name and folder name from name=
into classname= and adding a static placeholder for the classname.
{code:java}
{code}
Or if we considered the java package is a distraction when using dynamic tests
{code:java}
{code}
was:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
...
public class SampleTest {
@TestFactory
Collection createDynamicTests() {
List testList = new ArrayList<>();
testList.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
testList.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List root = new ArrayList<>();
root.add(DynamicContainer.dynamicContainer("aFolder", testList));
return root;
}
private static class MyExecutable implements Executable {
@Override
public void execute() throws Throwable {
}
}
}
{code}
When I run this in IDEA. I get the following hierarchical structure in the UI
treeview
* SampleTest
** createDynamicTests()
*** aFolder
test1
test2
Here we can see that dynamic tests are represented by IDEA as nested children
of the test method. We can open and close the "virtual packages" created as
usual to explore in the dynamically created test results. It is not a "flat
list".
Using surefire 3.0.0-m7, with the example "phrased" reporter configuration
enabled, it creates contents in surefire-reports like so:
{code:java}
{code}
Here all the nested synthetic tests are created as synthetic "methods" of a
single class in the HTML report. The DynamicContainer and DynamicTest names are
injected into the synthetic "method" name. That
[jira] [Updated] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[
https://issues.apache.org/jira/browse/SUREFIRE-2147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoff Soutter updated SUREFIRE-2147:
Description:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package pkg;
...
public class SampleTest {
@TestFactory
Collection createDynamicTests() {
List testList = new ArrayList<>();
testList.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
testList.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List root = new ArrayList<>();
root.add(DynamicContainer.dynamicContainer("aFolder", testList));
return root;
}
private static class MyExecutable implements Executable {
@Override
public void execute() throws Throwable {
}
}
}
{code}
When I run this in IDEA. I get the following hierarchical structure in the UI
treeview
* SampleTest
** createDynamicTests()
*** aFolder
test1
test2
Here we can see that dynamic tests are represented by IDEA as nested children
of the test method. We can open and close the "virtual packages" created as
usual to explore in the dynamically created test results. It is not a "flat
list".
Using surefire 3.0.0-m7, with the example "phrased" reporter configuration
enabled, it creates contents in surefire-reports like so:
{code:java}
{code}
Here all the nested synthetic tests are created as synthetic "methods" of a
single class in the HTML report. The DynamicContainer and DynamicTest names are
injected into the synthetic "method" name. That is, from a reporting
perspective, they are created as a flat list (also it seems the folder name is
in the wrong place, it seems it should be on the left of the method name, eg
"createDynamicTests() aFolder test1" in order for the report to match the
internal structure).
This doesn't scale nicely as the number of tests in the dynamically created
"folder" structure grows. We can't view the different DynamicContainers
separately in the rendered HTML reports. We can't get a breakdown on any
particular DynamicContainer in the rendered HTML reports.
h3. Solution Ideas
I think what we want here is that dynamic tests using dynamic containers should
have those container names structured as synthetic packages. This allows us the
benefits of having the nested structure modelled correctly in the HTML report.
That is, when mapping from DynamicTests to Java packages, we have:
|| Java Structure || Dynamic Test Structure ||
| package identifier | DynamicContainer name |
| simple class name | static placeholder (e.g. Tests) |
| method name | DynamicTest name |
I think we could do that by moving the method name and folder name from name=
into classname= and adding a static placeholder for the classname.
{code:java}
{code}
Or if we considered the java package is a distraction when using dynamic tests
{code:java}
{code}
was:
h3. Description of the issue
I created a simple example of JUnit5 DynamicContainer/DynamicTest
{code:java}
package samplepackage;
...
public class SampleTest {
@TestFactory
Collection createDynamicTests() {
List testList = new ArrayList<>();
testList.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
testList.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
List root = new ArrayList<>();
root.add(DynamicContainer.dynamicContainer("aFolder", testList));
return root;
}
private static class MyExecutable implements Executable {
@Override
public void execute() throws Throwable {
}
}
}
{code}
When I run this in IDEA. I get the following hierarchical structure in the UI
treeview
* SampleTest
** createDynamicTests()
*** aFolder
test1
test2
Here we can see that dynamic tests are represented by IDEA as nested children
of the test method. We can open and close the "virtual packages" created as
usual to explore in the dynamically created test results. It is not a "flat
list".
Using surefire 3.0.0-m7, with the example "phrased" reporter configuration
enabled, it creates contents in surefire-reports like so:
{code:java}
{code}
Here all the nested synthetic tests are created as synthetic "methods" of a
single class in the HTML report. The DynamicContainer and DynamicTest names are
injected into the synthetic "method" name. That is, from a reporting
perspective, they are created as a flat list (also it seems the folder name is
in the wrong place, it seems it should be on the left of the method name, eg
"createDynamicTests() aFolder test1" in order for the report to match the
internal structure).
This doesn't scale nicely as the number of tests in the dynamically created
"folder" structure grows. We can't view the different DynamicContainers
separately in the
[jira] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[ https://issues.apache.org/jira/browse/SUREFIRE-2147 ]
Geoff Soutter deleted comment on SUREFIRE-2147:
-
was (Author: gsoutter):
Checked surefire 3.2.2 and seems this has improved. Whereas before we get this
{code}
{code}
Looks like now we get
{code}
{code}
The Jenkins JUnit plugin now creates an hierarchical report. Saying that, it is
not ideal in Jenkins, as it lacks the synthetic "Test" name of this proposal.
This means there is no consistent mapping from container to package - the
"last" container is mapped to class, so
* (negative) on the TestReport page the last container "disappears" from the
package listing,
* (positive) there is no need to "click through" the synthetic "Tests" class to
see results.
TBH neither way is perfect, it is only a matter of choosing the least worst
option, but for my purpose having Containers mapping cleanly to Packages is
important.
Also, in case of a Test not having a Container, it is inconsistent.
{code}
{code}
I latest tested in 3.0.0-M7. Not sure exactly what fixed it, but these look
related
* M8 - SUREFIRE-2117
* M9 - SUREFIRE-2065
> JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
> ---
>
> Key: SUREFIRE-2147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2147
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M7
>Reporter: Geoff Soutter
>Priority: Major
>
> h3. Description of the issue
> I created a simple example of JUnit5 DynamicContainer/DynamicTest
> {code:java}
> package samplepackage;
> ...
> public class SampleTest {
> @TestFactory
> Collection createDynamicTests() {
> List testList = new ArrayList<>();
> testList.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
> testList.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
> List root = new ArrayList<>();
> root.add(DynamicContainer.dynamicContainer("aFolder", testList));
> return root;
> }
> private static class MyExecutable implements Executable {
> @Override
> public void execute() throws Throwable {
> }
> }
> }
> {code}
> When I run this in IDEA. I get the following hierarchical structure in the UI
> treeview
> * SampleTest
> ** createDynamicTests()
> *** aFolder
> test1
> test2
> Here we can see that dynamic tests are represented by IDEA as nested children
> of the test method. We can open and close the "virtual packages" created as
> usual to explore in the dynamically created test results. It is not a "flat
> list".
> Using surefire 3.0.0-m7, with the example "phrased" reporter configuration
> enabled, it creates contents in surefire-reports like so:
> {code:java}
>classname="samplepackage.SampleTest" time="0.02"/>
>classname="samplepackage.SampleTest" time="0.001"/>
> {code}
> Here all the nested synthetic tests are created as synthetic "methods" of a
> single class in the HTML report. The DynamicContainer and DynamicTest names
> are injected into the synthetic "method" name. That is, from a reporting
> perspective, they are created as a flat list (also it seems the folder name
> is in the wrong place, it seems it should be on the left of the method name,
> eg "createDynamicTests() aFolder test1" in order for the report to match the
> internal structure).
> This doesn't scale nicely as the number of tests in the dynamically created
> "folder" structure grows. We can't view the different DynamicContainers
> separately in the rendered HTML reports. We can't get a breakdown on any
> particular DynamicContainer in the rendered HTML reports.
> h3. Solution Ideas
> I think what we want here is that dynamic tests using dynamic containers
> should have those container names structured as synthetic packages. This
> allows us the benefits of having the nested structure modelled correctly in
> the HTML report.
> That is, when mapping from DynamicTests to Java packages, we have:
> || Java Structure || Dynamic Test Structure ||
> | package identifier | DynamicContainer name |
> | simple class name | static placeholder (e.g. Tests) |
> | method name | DynamicTest name |
>
> I think we could do that by moving the method name and folder name from name=
> into classname= and adding a static placeholder for the classname.
> {code:java}
>classname="samplepackage.SampleTest.createDynamicTests().aFolder.Tests"/>
>classname="samplepackage.SampleTest.createDynamicTests().aFolder.Tests"/>
> {code}
> Or if we considered the java package is a distraction when using dynamic tests
> {code:java}
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (SUREFIRE-2147) JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
[ https://issues.apache.org/jira/browse/SUREFIRE-2147 ]
Geoff Soutter deleted comment on SUREFIRE-2147:
-
was (Author: gsoutter):
Had a quick look at 3.2.5 to see if any changes.
Not sure if I noticed before, but tried 3.2.5 on a real use case, which maps a
folder structure into Dynamic tests. Therefore I have parent Containers nested
inside child Containers. The current implementation seems to throw away the
parent containers, only the leaf container is shown in the report.
I think I can live with the rest of the behaviour, but throwing away "parent"
container names fundamentally breaks my use case.
Hopefully I can set aside some time to do contribute a PR for this (although
I've promised that a few times already and yet to deliver anything. Sigh).
> JUnit5 DynamicContainer/DynamicTest report loses the hierarchical structure
> ---
>
> Key: SUREFIRE-2147
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2147
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M7
>Reporter: Geoff Soutter
>Priority: Major
>
> h3. Description of the issue
> I created a simple example of JUnit5 DynamicContainer/DynamicTest
> {code:java}
> package samplepackage;
> ...
> public class SampleTest {
> @TestFactory
> Collection createDynamicTests() {
> List testList = new ArrayList<>();
> testList.add(DynamicTest.dynamicTest("test1", new MyExecutable()));
> testList.add(DynamicTest.dynamicTest("test2", new MyExecutable()));
> List root = new ArrayList<>();
> root.add(DynamicContainer.dynamicContainer("aFolder", testList));
> return root;
> }
> private static class MyExecutable implements Executable {
> @Override
> public void execute() throws Throwable {
> }
> }
> }
> {code}
> When I run this in IDEA. I get the following hierarchical structure in the UI
> treeview
> * SampleTest
> ** createDynamicTests()
> *** aFolder
> test1
> test2
> Here we can see that dynamic tests are represented by IDEA as nested children
> of the test method. We can open and close the "virtual packages" created as
> usual to explore in the dynamically created test results. It is not a "flat
> list".
> Using surefire 3.0.0-m7, with the example "phrased" reporter configuration
> enabled, it creates contents in surefire-reports like so:
> {code:java}
>classname="samplepackage.SampleTest" time="0.02"/>
>classname="samplepackage.SampleTest" time="0.001"/>
> {code}
> Here all the nested synthetic tests are created as synthetic "methods" of a
> single class in the HTML report. The DynamicContainer and DynamicTest names
> are injected into the synthetic "method" name. That is, from a reporting
> perspective, they are created as a flat list (also it seems the folder name
> is in the wrong place, it seems it should be on the left of the method name,
> eg "createDynamicTests() aFolder test1" in order for the report to match the
> internal structure).
> This doesn't scale nicely as the number of tests in the dynamically created
> "folder" structure grows. We can't view the different DynamicContainers
> separately in the rendered HTML reports. We can't get a breakdown on any
> particular DynamicContainer in the rendered HTML reports.
> h3. Solution Ideas
> I think what we want here is that dynamic tests using dynamic containers
> should have those container names structured as synthetic packages. This
> allows us the benefits of having the nested structure modelled correctly in
> the HTML report.
> That is, when mapping from DynamicTests to Java packages, we have:
> || Java Structure || Dynamic Test Structure ||
> | package identifier | DynamicContainer name |
> | simple class name | static placeholder (e.g. Tests) |
> | method name | DynamicTest name |
>
> I think we could do that by moving the method name and folder name from name=
> into classname= and adding a static placeholder for the classname.
> {code:java}
>classname="samplepackage.SampleTest.createDynamicTests().aFolder.Tests"/>
>classname="samplepackage.SampleTest.createDynamicTests().aFolder.Tests"/>
> {code}
> Or if we considered the java package is a distraction when using dynamic tests
> {code:java}
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Bump org.junit:junit-bom from 5.10.1 to 5.10.2 [maven-doxia-sitetools]
dependabot[bot] opened a new pull request, #135: URL: https://github.com/apache/maven-doxia-sitetools/pull/135 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.10.1 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit:junit-bom's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[PR] Bump org.junit.jupiter:junit-jupiter-api from 5.10.1 to 5.10.2 [maven-dependency-tree]
dependabot[bot] opened a new pull request, #43: URL: https://github.com/apache/maven-dependency-tree/pull/43 Bumps [org.junit.jupiter:junit-jupiter-api](https://github.com/junit-team/junit5) from 5.10.1 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit.jupiter:junit-jupiter-api's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] Bump org.htmlunit:htmlunit from 3.9.0 to 3.10.0 [maven-surefire]
elharo merged PR #717: URL: https://github.com/apache/maven-surefire/pull/717 -- 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
[PR] Bump org.assertj:assertj-core from 3.25.2 to 3.25.3 [maven-archiver]
dependabot[bot] opened a new pull request, #53: URL: https://github.com/apache/maven-archiver/pull/53 Bumps [org.assertj:assertj-core](https://github.com/assertj/assertj) from 3.25.2 to 3.25.3. Release notes Sourced from https://github.com/assertj/assertj/releases;>org.assertj:assertj-core's releases. v.3.25.3 :bug: Bug Fixes Lock maven-clean-plugin version for all modules Core Fix a performance regression in the recursive comparison related to FieldLocation https://redirect.github.com/assertj/assertj/issues/3350;>#3350 Don't fail when the recursive comparison checks compared fields in collection elements https://redirect.github.com/assertj/assertj/issues/3349;>#3349 (proper fix: https://redirect.github.com/assertj/assertj/issues/3354;>#3354) :hammer: Dependency Upgrades Upgrade to Flatten Maven Plugin 1.6.0 https://redirect.github.com/assertj/assertj/issues/3335;>#3335 Upgrade to Groovy 4.0.18 https://redirect.github.com/assertj/assertj/issues/3347;>#3347 Upgrade to Hibernate Core 6.4.2.Final https://redirect.github.com/assertj/assertj/issues/3338;>#3338 Upgrade to Maven Surefire Report Plugin 3.2.5 https://redirect.github.com/assertj/assertj/issues/3330;>#3330 Upgrade to PITest Maven 1.15.6 https://redirect.github.com/assertj/assertj/issues/3348;>#3348 Upgrade to SpotBugs Maven Plugin 4.8.3.0 https://redirect.github.com/assertj/assertj/issues/3336;>#3336 Upgrade to advanced-security/maven-dependency-submission-action to 4 https://redirect.github.com/assertj/assertj/issues/3346;>#3346 :heart: Contributors Thanks to all the contributors who worked on this release: https://github.com/ash211;>@​ash211 Commits https://github.com/assertj/assertj/commit/cd72df8cf56e2b7dc6f560cc1066c3643920fe7f;>cd72df8 [maven-release-plugin] prepare release assertj-build-3.25.3 https://github.com/assertj/assertj/commit/c9b3177ad8b133f3b71f95fe94a4f7d9e92d841c;>c9b3177 fix: missing license https://github.com/assertj/assertj/commit/ae62aca8688421652a00b7d8660db30bc4b4a6ad;>ae62aca Ignore containers when checking compared fields existence in the recursive co... https://github.com/assertj/assertj/commit/bad16efa2bdb181983776b71ecbbcf83032609f5;>bad16ef chore(deps-dev): bump org.hibernate.orm:hibernate-core from 6.4.2.Final to 6 https://github.com/assertj/assertj/commit/c7940570d5b3f5743ac221e303733aeb1c0e6527;>c794057 Fix a performance regression in the recursive comparison related to FieldLoca... https://github.com/assertj/assertj/commit/9ecb7f48689f5effaf601f637d9a75a4c5749693;>9ecb7f4 Lock maven-clean-plugin version for all modules https://github.com/assertj/assertj/commit/d42d40c7d2d35fade2c5da6d0a85d2d3bc4e79cf;>d42d40c chore(deps): bump org.pitest:pitest-maven from 1.15.3 to 1.15.6 (https://redirect.github.com/assertj/assertj/issues/3348;>#3348) https://github.com/assertj/assertj/commit/5b32492639129a2cc01864515fe882c224534e20;>5b32492 chore(deps): bump org.apache.maven.plugins:maven-surefire-report-plugin from ... https://github.com/assertj/assertj/commit/e27cc02080179339948a5ec9ca8dabea5abff3dc;>e27cc02 chore(deps): bump org.codehaus.mojo:flatten-maven-plugin from 1.5.0 to 1.6.0 ... https://github.com/assertj/assertj/commit/97710916f7f750d0ee9a8857b978c7393386571c;>9771091 chore(deps): bump com.github.spotbugs:spotbugs-maven-plugin from 4.8.2.0 to 4... Additional commits viewable in https://github.com/assertj/assertj/compare/assertj-build-3.25.2...assertj-build-3.25.3;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the
[PR] Bump org.junit:junit-bom from 5.10.1 to 5.10.2 [maven-archiver]
dependabot[bot] opened a new pull request, #52: URL: https://github.com/apache/maven-archiver/pull/52 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.10.1 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit:junit-bom's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] Bump org.junit:junit-bom from 5.9.3 to 5.10.1 [maven-surefire]
dependabot[bot] closed pull request #685: Bump org.junit:junit-bom from 5.9.3 to 5.10.1 URL: https://github.com/apache/maven-surefire/pull/685 -- 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
[PR] Bump org.junit:junit-bom from 5.9.3 to 5.10.2 [maven-surefire]
dependabot[bot] opened a new pull request, #720: URL: https://github.com/apache/maven-surefire/pull/720 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.9.3 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit:junit-bom's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 JUnit 5.10.1 = Platform 1.10.1 + Jupiter 5.10.1 + Vintage 5.10.1 See http://junit.org/junit5/docs/5.10.1/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.0...r5.10.1;>https://github.com/junit-team/junit5/compare/r5.10.0...r5.10.1 JUnit 5.10.0 = Platform 1.10.0 + Jupiter 5.10.0 + Vintage 5.10.0 See http://junit.org/junit5/docs/5.10.0/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.0-RC2...r5.10.0;>https://github.com/junit-team/junit5/compare/r5.10.0-RC2...r5.10.0 JUnit 5.10.0-RC2 = Platform 1.10.0-RC2+ Jupiter 5.10.0-RC2 + Vintage 5.10.0-RC2 See http://junit.org/junit5/docs/5.10.0-RC2/release-notes/;>Release Notes. JUnit 5.10.0-RC1 = Platform 1.10.0-RC1 + Jupiter 5.10.0-RC1 + Vintage 5.10.0-RC1 See http://junit.org/junit5/docs/5.10.0-RC1/release-notes/;>Release Notes. JUnit 5.10.0-M1 = Platform 1.10.0-M1 + Jupiter 5.10.0-M1 + Vintage 5.10.0-M1 See http://junit.org/junit5/docs/5.10.0-M1/release-notes/;>Release Notes. Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.9.3...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) -
Re: [PR] Bump org.junit:junit-bom from 5.9.3 to 5.10.1 [maven-surefire]
dependabot[bot] commented on PR #685: URL: https://github.com/apache/maven-surefire/pull/685#issuecomment-1927933238 Superseded by #720. -- 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] Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 [maven-surefire]
dependabot[bot] commented on PR #718: URL: https://github.com/apache/maven-surefire/pull/718#issuecomment-1927932211 Superseded by #719. -- 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] Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 [maven-surefire]
dependabot[bot] closed pull request #718: Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 URL: https://github.com/apache/maven-surefire/pull/718 -- 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
[PR] Bump org.assertj:assertj-core from 3.25.1 to 3.25.3 [maven-surefire]
dependabot[bot] opened a new pull request, #719: URL: https://github.com/apache/maven-surefire/pull/719 Bumps [org.assertj:assertj-core](https://github.com/assertj/assertj) from 3.25.1 to 3.25.3. Release notes Sourced from https://github.com/assertj/assertj/releases;>org.assertj:assertj-core's releases. v.3.25.3 :bug: Bug Fixes Lock maven-clean-plugin version for all modules Core Fix a performance regression in the recursive comparison related to FieldLocation https://redirect.github.com/assertj/assertj/issues/3350;>#3350 Don't fail when the recursive comparison checks compared fields in collection elements https://redirect.github.com/assertj/assertj/issues/3349;>#3349 (proper fix: https://redirect.github.com/assertj/assertj/issues/3354;>#3354) :hammer: Dependency Upgrades Upgrade to Flatten Maven Plugin 1.6.0 https://redirect.github.com/assertj/assertj/issues/3335;>#3335 Upgrade to Groovy 4.0.18 https://redirect.github.com/assertj/assertj/issues/3347;>#3347 Upgrade to Hibernate Core 6.4.2.Final https://redirect.github.com/assertj/assertj/issues/3338;>#3338 Upgrade to Maven Surefire Report Plugin 3.2.5 https://redirect.github.com/assertj/assertj/issues/3330;>#3330 Upgrade to PITest Maven 1.15.6 https://redirect.github.com/assertj/assertj/issues/3348;>#3348 Upgrade to SpotBugs Maven Plugin 4.8.3.0 https://redirect.github.com/assertj/assertj/issues/3336;>#3336 Upgrade to advanced-security/maven-dependency-submission-action to 4 https://redirect.github.com/assertj/assertj/issues/3346;>#3346 :heart: Contributors Thanks to all the contributors who worked on this release: https://github.com/ash211;>@​ash211 v3.25.2 :bug: Bug Fixes Fix unresolvable Javadoc stylesheet URLs, simplify configuration https://redirect.github.com/assertj/assertj/issues/3324;>#3324 Core Fix missing configuration for MatcherAssert soft assertions Make deprecation notice visible in AbstractAssert#asList https://redirect.github.com/assertj/assertj/issues/3327;>#3327 Recursive comparison uses equals on root object when useOverriddenEquals is enabled https://redirect.github.com/assertj/assertj/issues/3320;>#3320 satisfiesExactlyInAnyOrder fails if actual overrides equals https://redirect.github.com/assertj/assertj/issues/3339;>#3339 Avoid calling actual.hashCode() and expected.hashCode() in DualValue https://redirect.github.com/assertj/assertj/issues/3340;>#3340 Recursive comparison checks for existence of fields in types that parameterize nested unordered iterables https://redirect.github.com/assertj/assertj/issues/3332;>#3332 :hammer: Dependency Upgrades Upgrade to EqualsVerifier 3.15.6 https://redirect.github.com/assertj/assertj/issues/3329;>#3329 Upgrade to Maven Surefire Plugin 3.2.5 https://redirect.github.com/assertj/assertj/issues/3328;>#3328 Upgrade to Spotless Maven Plugin 2.43.0 https://redirect.github.com/assertj/assertj/issues/3345;>#3345 :heart: Contributors Thanks to all the contributors who worked on this release: ... (truncated) Commits https://github.com/assertj/assertj/commit/cd72df8cf56e2b7dc6f560cc1066c3643920fe7f;>cd72df8 [maven-release-plugin] prepare release assertj-build-3.25.3 https://github.com/assertj/assertj/commit/c9b3177ad8b133f3b71f95fe94a4f7d9e92d841c;>c9b3177 fix: missing license https://github.com/assertj/assertj/commit/ae62aca8688421652a00b7d8660db30bc4b4a6ad;>ae62aca Ignore containers when checking compared fields existence in the recursive co... https://github.com/assertj/assertj/commit/bad16efa2bdb181983776b71ecbbcf83032609f5;>bad16ef chore(deps-dev): bump org.hibernate.orm:hibernate-core from 6.4.2.Final to 6 https://github.com/assertj/assertj/commit/c7940570d5b3f5743ac221e303733aeb1c0e6527;>c794057 Fix a performance regression in the recursive comparison related to FieldLoca... https://github.com/assertj/assertj/commit/9ecb7f48689f5effaf601f637d9a75a4c5749693;>9ecb7f4 Lock maven-clean-plugin version for all modules https://github.com/assertj/assertj/commit/d42d40c7d2d35fade2c5da6d0a85d2d3bc4e79cf;>d42d40c chore(deps): bump org.pitest:pitest-maven from 1.15.3 to 1.15.6 (https://redirect.github.com/assertj/assertj/issues/3348;>#3348) https://github.com/assertj/assertj/commit/5b32492639129a2cc01864515fe882c224534e20;>5b32492 chore(deps): bump org.apache.maven.plugins:maven-surefire-report-plugin from ... https://github.com/assertj/assertj/commit/e27cc02080179339948a5ec9ca8dabea5abff3dc;>e27cc02 chore(deps): bump org.codehaus.mojo:flatten-maven-plugin from 1.5.0 to 1.6.0 ... https://github.com/assertj/assertj/commit/97710916f7f750d0ee9a8857b978c7393386571c;>9771091 chore(deps): bump com.github.spotbugs:spotbugs-maven-plugin from 4.8.2.0 to 4... Additional commits viewable in
[jira] [Resolved] (MWRAPPER-112) Detection of JAVA_HOME fails due to bad quoting
[
https://issues.apache.org/jira/browse/MWRAPPER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MWRAPPER-112.
---
Resolution: Fixed
> Detection of JAVA_HOME fails due to bad quoting
> ---
>
> Key: MWRAPPER-112
> URL: https://issues.apache.org/jira/browse/MWRAPPER-112
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
> Environment: Ubuntu 20.04, Java 17
>Reporter: Ingo Karkat
>Assignee: Benjamin Marwell
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 3.3.0
>
>
> I have a standard Ubuntu 20.04 Java installation ({{{}openjdk-17-jdk{}}} APT
> package, {{/usr/bin/javac}} linked to
> {{/usr/lib/jvm/java-17-openjdk-amd64/bin/javac}} via the update-alternatives
> system, no {{JAVA_HOME}} set). Maven Wrapper 3.2.0 should detect that, but on
> each invocation prints this warning:
> {{Warning: JAVA_HOME environment variable is not set.}}
> This is caused by excessive quoting (i.e. the {{{}\"{}}}):
> {{javaExecutable="$(readlink -f "\"$javaExecutable\"")"}}
> Apparently, that code has been in the codebase since the beginning, taken
> over from the {{gradlew}} wrapper (which had the shell wrappers completely
> rewritten; there are no remnants of this code found there any longer).
> Pull request: https://github.com/apache/maven-wrapper/pull/102
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814478#comment-17814478
]
Tamas Cservenak edited comment on MNG-7906 at 2/5/24 6:48 PM:
--
Moreover, to extend Guillaumes point: "project version" {{G:A:1.x}} can change
to {{G:A2:2.x}} as Maven GAV (you have two more coordinates to "express" the
intent) is not "version only" as in npm, ruby-gems etc. You could even "encode"
major version in A, so shift in x.y.z version into {{groupId:artifact-x:y.z}}
or alike (this is just for example sake). Moreover, there is a long history of
changes like these even in ASF history.
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
was (Author: cstamas):
Moreover, to extend Guillaumes point: "project version" {(A:1.x}} can change to
{{G:A2:2.x}} as Maven GAV (you have two more coordinates to "express" the
intent) is not "version only" as in npm, ruby-gems etc. You could even "encode"
major version in A, so shift in x.y.z version into {{groupId:artifact-x:y.z}}
or alike (this is just for example sake). Moreover, there is a long history of
changes like these even in ASF history.
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814478#comment-17814478
]
Tamas Cservenak edited comment on MNG-7906 at 2/5/24 6:47 PM:
--
Moreover, to extend Guillaumes point: "project version" {(A:1.x}} can change to
{{G:A2:2.x}} as Maven GAV (you have two more coordinates to "express" the
intent) is not "version only" as in npm, ruby-gems etc. You could even "encode"
major version in A, so shift in x.y.z version into {{groupId:artifact-x:y.z}}
or alike (this is just for example sake). Moreover, there is a long history of
changes like these even in ASF history.
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
was (Author: cstamas):
Moreover, to extend Guillaume point: "project version" {(A:1.x}} can change to
\{{G:A2:2.x}} as Maven GAV (remember, you have two more coordinates to
"express" the intent) not found.) is not "version only". You could even
"encode" major version in A, so shift in x.y.z version into
{{groupId:artifact-x:y.z}} or alike (this is just for exampel sake).
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-112) Detection of JAVA_HOME fails due to bad quoting
[
https://issues.apache.org/jira/browse/MWRAPPER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814481#comment-17814481
]
ASF GitHub Bot commented on MWRAPPER-112:
-
bmarwell merged PR #102:
URL: https://github.com/apache/maven-wrapper/pull/102
> Detection of JAVA_HOME fails due to bad quoting
> ---
>
> Key: MWRAPPER-112
> URL: https://issues.apache.org/jira/browse/MWRAPPER-112
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
> Environment: Ubuntu 20.04, Java 17
>Reporter: Ingo Karkat
>Assignee: Benjamin Marwell
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 3.3.0
>
>
> I have a standard Ubuntu 20.04 Java installation ({{{}openjdk-17-jdk{}}} APT
> package, {{/usr/bin/javac}} linked to
> {{/usr/lib/jvm/java-17-openjdk-amd64/bin/javac}} via the update-alternatives
> system, no {{JAVA_HOME}} set). Maven Wrapper 3.2.0 should detect that, but on
> each invocation prints this warning:
> {{Warning: JAVA_HOME environment variable is not set.}}
> This is caused by excessive quoting (i.e. the {{{}\"{}}}):
> {{javaExecutable="$(readlink -f "\"$javaExecutable\"")"}}
> Apparently, that code has been in the codebase since the beginning, taken
> over from the {{gradlew}} wrapper (which had the shell wrappers completely
> rewritten; there are no remnants of this code found there any longer).
> Pull request: https://github.com/apache/maven-wrapper/pull/102
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-112) Detection of JAVA_HOME fails due to bad quoting
[
https://issues.apache.org/jira/browse/MWRAPPER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814480#comment-17814480
]
ASF GitHub Bot commented on MWRAPPER-112:
-
bmarwell commented on PR #102:
URL: https://github.com/apache/maven-wrapper/pull/102#issuecomment-1927793833
I was just pointed to a mail that since GitHub, ICLAs are only required for
committers. Sorry, I didn't know better (but now I do).
> Detection of JAVA_HOME fails due to bad quoting
> ---
>
> Key: MWRAPPER-112
> URL: https://issues.apache.org/jira/browse/MWRAPPER-112
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
> Environment: Ubuntu 20.04, Java 17
>Reporter: Ingo Karkat
>Assignee: Benjamin Marwell
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 3.3.0
>
>
> I have a standard Ubuntu 20.04 Java installation ({{{}openjdk-17-jdk{}}} APT
> package, {{/usr/bin/javac}} linked to
> {{/usr/lib/jvm/java-17-openjdk-amd64/bin/javac}} via the update-alternatives
> system, no {{JAVA_HOME}} set). Maven Wrapper 3.2.0 should detect that, but on
> each invocation prints this warning:
> {{Warning: JAVA_HOME environment variable is not set.}}
> This is caused by excessive quoting (i.e. the {{{}\"{}}}):
> {{javaExecutable="$(readlink -f "\"$javaExecutable\"")"}}
> Apparently, that code has been in the codebase since the beginning, taken
> over from the {{gradlew}} wrapper (which had the shell wrappers completely
> rewritten; there are no remnants of this code found there any longer).
> Pull request: https://github.com/apache/maven-wrapper/pull/102
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MWRAPPER-112] Detection of JAVA_HOME fails due to bad quoting [maven-wrapper]
bmarwell merged PR #102: URL: https://github.com/apache/maven-wrapper/pull/102 -- 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] [MWRAPPER-112] Detection of JAVA_HOME fails due to bad quoting [maven-wrapper]
bmarwell commented on PR #102: URL: https://github.com/apache/maven-wrapper/pull/102#issuecomment-1927793833 I was just pointed to a mail that since GitHub, ICLAs are only required for committers. Sorry, I didn't know better (but now I do). -- 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] [Comment Edited] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814478#comment-17814478
]
Tamas Cservenak edited comment on MNG-7906 at 2/5/24 6:45 PM:
--
Moreover, to extend Guillaume point: "project version" {(A:1.x}} can change to
\{{G:A2:2.x}} as Maven GAV (remember, you have two more coordinates to
"express" the intent) not found.) is not "version only". You could even
"encode" major version in A, so shift in x.y.z version into
{{groupId:artifact-x:y.z}} or alike (this is just for exampel sake).
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
was (Author: cstamas):
Moreover, to extend Guillaume point: "project version" != "artifact version"
(or it does not have to be). There is a long history, that a project that
evolves, and assuming it gets incompatible changes, change the GAV as well (to
be clear about incompatible changes). So, {{G:A:1.x}} can change to
{{G:A2:2.x}} as Maven GAV (remember, you have two more coordinates to "express"
the intent!) is not "version only". You could even "encode" major version in A,
so shift in x.y.z version into {{groupId:artifact-x:y.z}} or alike (this is
just for exampel sake).
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814478#comment-17814478
]
Tamas Cservenak commented on MNG-7906:
--
Moreover, to extend Guillaume point: "project version" != "artifact version"
(or it does not have to be). There is a long history, that a project that
evolves, and assuming it gets incompatible changes, change the GAV as well (to
be clear about incompatible changes). So, {{G:A:1.x}} can change to
{{G:A2:2.x}} as Maven GAV (remember, you have two more coordinates to "express"
the intent!) is not "version only". You could even "encode" major version in A,
so shift in x.y.z version into {{groupId:artifact-x:y.z}} or alike (this is
just for exampel sake).
This is a reason more why "semantic versioning" is not one-to-one applicable to
Maven universe, simply put, maven universe is "broader" than that laid down by
SemVer.
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Bump org.junit.jupiter:junit-jupiter-api from 5.10.1 to 5.10.2 [maven-filtering]
dependabot[bot] opened a new pull request, #95: URL: https://github.com/apache/maven-filtering/pull/95 Bumps [org.junit.jupiter:junit-jupiter-api](https://github.com/junit-team/junit5) from 5.10.1 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit.jupiter:junit-jupiter-api's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM). Just as detail: if Resolver would be asked to
create root, it would NOT add these in the first place. Due these present,
conflict resolver may possibly eliminate other nodes (as POM ones "always
wins", are the closest to graph root. Finally, these winners may be eliminated
in subsequent step, for example due scope filtering. This results in incomplete
resolution scope.
Example: let's consider example where Mojo asks for "runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" using Resolver. When Resolver returns the graph, it will
contain nodes (as 1st level was populated by Maven) that MAY be contained in
deeper nodes of non-test scoped ones (the guice+guava example). Next, "conflict
resolution" happens, and naturally all the "test" scoped 1st level dependencies
will "win", rendering removal of others. Finally, due "runtime" requested
resolution scope, the "test" scoped dependencies are (rightfully) filtered out.
{*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
Effects of this bug are explained in "Important Consequences" section of this
page
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
(that is wrongly written: all that is a consequence of this bug). Also, have
to note, that when this bug get addressed, it will NOT render "workarounds"
broken (ie. introduction of another module just to package "runtime" classpath
using m-assembly-p or alike plugins), just "obsolete", as packaging of runtime
dependencies will become possible in-situ (in the same module of the project).
Exercises: check out reproducer and execute these commands:
* {{mvn dependency:tree}} => OK, it shows "dependencies included from all
scopes" (this is equiv to "test" build scope), guava is in test scope
* {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
this bug, guava is missing from runtime resolution scope
* install the reproducer project into local repository, and create another
project (or use {{downstream/pom.xml}} from reproducer) that uses reproducer
project as dependency (only one, no depMgt and so on), ask for {{mvn
dependency:tree}} => OK (and look! Guava IS there)
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM). Just as detail: if Resolver would be asked to
create root, it would NOT add these in the first place. Due these present,
conflict resolver may possibly eliminate other nodes (as POM ones "always
wins", are the closest to graph root. Finally, these winners may be eliminated
in subsequent step, for example due scope filtering. This results in incomplete
resolution scope.
Example: let's consider example where Mojo asks for "runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" using Resolver. When Resolver returns the graph, it will
contain nodes (as 1st level was populated by Maven) that MAY be contained in
deeper nodes of non-test scoped ones (the guice+guava example). Next, "conflict
resolution" happens, and naturally all the "test" scoped 1st level dependencies
will "win", rendering removal of others. Finally, due "runtime" requested
resolution scope, the "test" scoped dependencies are (rightfully) filtered out.
{*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
Effects of this bug are explained in "Important Consequences" section of this
page
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
(that is wrongly written: all that is a consequence of this bug). Also, have
to note, that when this bug get addressed, it will NOT render "workarounds"
broken (ie. introduction of another module just to package "runtime" classpath
using m-assembly-p or alike plugins), just "obsolete", as packaging of runtime
dependencies will become possible in-situ (in the same module of the project).
Exercises: check out reproducer and execute these commands:
* {{mvn dependency:tree}} => OK, it shows "dependencies included from all
scopes" (this is equiv to "test" build scope), guava is in test scope
* {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
this bug, guava is missing
* install the reproducer project into local repository, and create another
project (or use {{downstream/pom.xml}} from reproducer) that uses reproducer
project as dependency (only one, no depMgt and so on), ask for {{mvn
dependency:tree}} => OK (and look! Guava IS there)
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM). Just as detail: if Resolver would be asked to
create root, it would NOT add these in the first place. Due these present,
conflict resolver may possibly eliminate other nodes (as POM ones "always
wins", are the closest to graph root. Finally, these winners may be eliminated
in subsequent step, for example due scope filtering. This results in incomplete
resolution scope.
Example: let's consider example where Mojo asks for "runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" using Resolver. When Resolver returns the graph, it will
contain nodes (as 1st level was populated by Maven) that MAY be contained in
deeper nodes of non-test scoped ones (the guice+guava example). Next, "conflict
resolution" happens, and naturally all the "test" scoped 1st level dependencies
will "win", rendering removal of others. Finally, due "runtime" requested
resolution scope, the "test" scoped dependencies are (rightfully) filtered out.
{*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
Effects of this bug are explained in "Important Consequences" section of this
page
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
(that is wrongly written: all that is a consequence of this bug). Also, have
to note, that when this bug get addressed, it will NOT render "workarounds"
broken (ie. introduction of another module just to package "runtime" classpath
using m-assembly-p or alike plugins), just "obsolete", as packaging of runtime
dependencies will become possible in-situ (in the same module of the project).
Exercises: check out reproducer and execute these commands:
* {{mvn dependency:tree}} => OK, it shows "dependencies included from all
scopes" (this is equiv to "test" build scope)
* {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
this bug (guava missing)
* install the reproducer project into local repository, and create another
project (or use {{downstream/pom.xml}} from reproducer) that uses reproducer
project as dependency (only one, no depMgt and so on), ask for {{mvn
dependency:tree}} => OK (and look! Guava IS there)
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM). Just as detail: if Resolver would be asked to
create root, it would NOT add these in the first place. Due these present,
conflict resolver may possibly eliminate other nodes (as POM ones "always
wins", are the closest to graph root. Finally, these winners may be eliminated
in subsequent step, for example due scope filtering. This results in incomplete
resolution scope.
Example: let's consider example where Mojo asks for "runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" using Resolver. When Resolver returns the graph, it will
contain nodes (as 1st level was populated by Maven) that MAY be contained in
deeper nodes of non-test scoped ones (the guice+guava example). Next, "conflict
resolution" happens, and naturally all the "test" scoped 1st level dependencies
will "win", rendering removal of others. Finally, due "runtime" requested
resolution scope, the "test" scoped dependencies are (rightfully) filtered out.
{*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
Effects of this bug are explained in "Important Consequences" section of this
page
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
(that is wrongly written: all that is a consequence of this bug). Also, have
to note, that when this bug get addressed, it will NOT render "workarounds"
broken (ie. introduction of another module just to package "runtime" classpath
using m-assembly-p or alike plugins), just "obsolete", as packaging of runtime
dependencies will become possible in-situ (in the same module of the project).
Exercises:
* check out reproducer and install it into local repository, then execute
these commands:
** {{mvn dependency:tree}} => OK, it shows "dependencies included from all
scopes" (this is equiv to "test" build scope)
** {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
this bug (guava missing)
** install the reproducer project into local repository, and create another
project (or use {{downstream/pom.xml}} from reproducer) that uses reproducer
project as dependency (only one, no depMgt and so on), ask for {{mvn
dependency:tree}} => OK (and look! Guava IS there)
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM). Just as detail: if Resolver would be asked to
create root, it would NOT add these in the first place. Due these present,
conflict resolver may possibly eliminate other nodes (as POM ones "always
wins", are the closest to graph root. Finally, these winners may be eliminated
in subsequent step, for example due scope filtering. This results in incomplete
resolution scope.
Example: let's consider example where Mojo asks for "runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" using Resolver. When Resolver returns the graph, it will
contain nodes (as 1st level was populated by Maven) that MAY be contained in
deeper nodes of non-test scoped ones (the guice+guava example). Next, "conflict
resolution" happens, and naturally all the "test" scoped 1st level dependencies
will "win", rendering removal of others. Finally, due "runtime" requested
resolution scope, the "test" scoped dependencies are (rightfully) filtered out.
{*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
Effects of this bug are explained in "Important Consequences" section of this
page
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
(that is wrongly written: all that is a consequence of this bug). Also, have
to note, that when this bug get addressed, it will NOT render "workarounds"
broken (ie. introduction of another module just to package "runtime" classpath
using m-assembly-p or alike plugins), just "obsolete", as packaging of runtime
dependencies will become possible in-situ (in the same module of the project).
Excercies:
* check out reproducer and install it into local repository, then execute
these commands:
** {{mvn dependency:tree}} => OK, it shows "dependencies included from all
scopes" (this is equiv to "test" build scope)
** {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
this bug (guava missing)
** install the reproducer project into local repository, and create another
project (or use {{downstream/pom.xml}} from reproducer) that uses reproducer
project as dependency (only one, no depMgt and so on), ask for {{mvn
dependency:tree}} => OK (and look! Guava IS there)
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM). Just as detail: if Resolver would be asked to
create root, it would NOT add these in the first place. Due these present,
conflict resolver may possibly eliminate other nodes (as POM ones "always
wins", are the closest to graph root. Finally, these winners may be eliminated
in subsequent step, for example due scope filtering. This results in incomplete
resolution scope.
Example: let's consider example where Mojo asks for "runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" using Resolver. When Resolver returns the graph, it will
contain nodes (as 1st level was populated by Maven) that MAY be contained in
deeper nodes of non-test scoped ones (the guice+guava example). Next, "conflict
resolution" happens, and naturally all the "test" scoped 1st level dependencies
will "win", rendering removal of others. Finally, due "runtime" requested
resolution scope, the "test" scoped dependencies are (rightfully) filtered out.
{*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
Effects of this bug are explained in "Important Consequences" section of this
page
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
(that is wrongly written: all that is a consequence of this bug). Also, have
to note, that when this bug get addressed, it will NOT render "workarounds"
broken (ie. introduction of another module just to package "runtime" classpath
using m-assembly-p or alike plugins), just "obsolete", as packaging of runtime
dependencies will become possible in-situ (in the same module of the project).
Excercies:
* check out reproducer and install it into local repository, then execute
these commands:
** {{mvn dependency:tree}} => OK, it shows "dependencies included from all
scopes" (this is equiv to "test" build scope)
** {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
this bug (guava missing)
** install the reproducer project, and create another project that uses
reproducer project as dependency (only one, no depMgt and so on), ask for {{mvn
dependency:tree}} => OK (and look! Guava IS there)
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with
[jira] [Commented] (SUREFIRE-1934) Ability to disable system-out/system-err for successfuly passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814436#comment-17814436 ] ASF GitHub Bot commented on SUREFIRE-1934: -- michael-o commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1927432700 > Hey @michael-o, according to [a previous comment](https://github.com/apache/maven-surefire/pull/670#issuecomment-1863815281) it seems that the intention of @NissMoony was to provide an option for suppressing all output (irrespective of the type of the result) from the XML report. > > For our use-case (Apache Hive), I think that disabling all output from the **XML report** is sufficient to move our upgrade further assuming that `redirectTestOutputToFile` option works as before and will still send the STDOUT to a file irrespective of the the changes introduced by this PR. > > Having more fine grained configurations (e.g., only apply this on successful/failed tests) may be a nice to have feature but not a strong requirement from our side at this point. We all understand that complex configurations are hard to maintain. The code contradicts the issue summary. Either one should be picked. > Ability to disable system-out/system-err for successfuly passed tests > - > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Priority: Major > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-1934] Ability to disable system-out/system-err for successfuly passed tests. [maven-surefire]
michael-o commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1927432700 > Hey @michael-o, according to [a previous comment](https://github.com/apache/maven-surefire/pull/670#issuecomment-1863815281) it seems that the intention of @NissMoony was to provide an option for suppressing all output (irrespective of the type of the result) from the XML report. > > For our use-case (Apache Hive), I think that disabling all output from the **XML report** is sufficient to move our upgrade further assuming that `redirectTestOutputToFile` option works as before and will still send the STDOUT to a file irrespective of the the changes introduced by this PR. > > Having more fine grained configurations (e.g., only apply this on successful/failed tests) may be a nice to have feature but not a strong requirement from our side at this point. We all understand that complex configurations are hard to maintain. The code contradicts the issue summary. Either one should be picked. -- 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] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM). Just as detail: if Resolver would be asked to
create root, it would NOT add these in the first place. Due these present,
conflict resolver may possibly eliminate other nodes (as POM ones "always
wins", are the closest to graph root. Finally, these winners may be eliminated
in subsequent step, for example due scope filtering. This results in incomplete
resolution scope.
Example: let's consider example where Mojo asks for "runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" using Resolver. When Resolver returns the graph, it will
contain nodes (as 1st level was populated by Maven) that MAY be contained in
deeper nodes of non-test scoped ones (the guice+guava example). Next, "conflict
resolution" happens, and naturally all the "test" scoped 1st level dependencies
will "win", rendering removal of others. Finally, due "runtime" requested
resolution scope, the "test" scoped dependencies are (rightfully) filtered out.
{*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
Effects of this bug are explained in "Important Consequences" section of this
page
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
(that is wrongly written: all that is a consequence of this bug). Also, have
to note, that when this bug get addressed, it will NOT render "workarounds"
broken (ie. introduction of another module just to package "runtime" classpath
using m-assembly-p or alike plugins), just "obsolete", as packaging of runtime
dependencies will become possible in-situ (in the same module of the project).
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope
[jira] [Commented] (MWRAPPER-112) Detection of JAVA_HOME fails due to bad quoting
[
https://issues.apache.org/jira/browse/MWRAPPER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814433#comment-17814433
]
ASF GitHub Bot commented on MWRAPPER-112:
-
inkarkat commented on PR #102:
URL: https://github.com/apache/maven-wrapper/pull/102#issuecomment-1927412123
Alright, I've sent the signed ICLA to the secretary email address (I was
under the impression that this change of < 20 lines and basically just
deletions didn't require one).
May I also draw your attention to #106 - the second PR from me that fixes
another issue in the wrapper scripts?! I've just freshly rebased that one.
> Detection of JAVA_HOME fails due to bad quoting
> ---
>
> Key: MWRAPPER-112
> URL: https://issues.apache.org/jira/browse/MWRAPPER-112
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.2.0, 3.3.0
> Environment: Ubuntu 20.04, Java 17
>Reporter: Ingo Karkat
>Assignee: Benjamin Marwell
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 3.3.0
>
>
> I have a standard Ubuntu 20.04 Java installation ({{{}openjdk-17-jdk{}}} APT
> package, {{/usr/bin/javac}} linked to
> {{/usr/lib/jvm/java-17-openjdk-amd64/bin/javac}} via the update-alternatives
> system, no {{JAVA_HOME}} set). Maven Wrapper 3.2.0 should detect that, but on
> each invocation prints this warning:
> {{Warning: JAVA_HOME environment variable is not set.}}
> This is caused by excessive quoting (i.e. the {{{}\"{}}}):
> {{javaExecutable="$(readlink -f "\"$javaExecutable\"")"}}
> Apparently, that code has been in the codebase since the beginning, taken
> over from the {{gradlew}} wrapper (which had the shell wrappers completely
> rewritten; there are no remnants of this code found there any longer).
> Pull request: https://github.com/apache/maven-wrapper/pull/102
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MWRAPPER-112] Detection of JAVA_HOME fails due to bad quoting [maven-wrapper]
inkarkat commented on PR #102: URL: https://github.com/apache/maven-wrapper/pull/102#issuecomment-1927412123 Alright, I've sent the signed ICLA to the secretary email address (I was under the impression that this change of < 20 lines and basically just deletions didn't require one). May I also draw your attention to #106 - the second PR from me that fixes another issue in the wrapper scripts?! I've just freshly rebased that one. -- 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] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814421#comment-17814421 ] Tamas Cservenak commented on MRESOLVER-391: --- Well, this is NOT a resolver issue as I did prove it is not. And, if I'd not listen to my feelings, we'd not be here, but would continue the debate :P > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814414#comment-17814414 ] Henning Schmiedehausen commented on MRESOLVER-391: -- Well, that was a journey from "I have a feeling this/these issues is/are NOT resolver issues (it seems fine), but a _series of bugs_ in some of plugins".  Proves again, that you should never trust your feelings. :) > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump org.codehaus.plexus:plexus-interactivity-api from 1.2 to 1.3 [maven-help-plugin]
dependabot[bot] opened a new pull request, #107: URL: https://github.com/apache/maven-help-plugin/pull/107 Bumps [org.codehaus.plexus:plexus-interactivity-api](https://github.com/codehaus-plexus/plexus-interactivity) from 1.2 to 1.3. Commits https://github.com/codehaus-plexus/plexus-interactivity/commit/c4f05e2651c9479ad2819911abc1559bd417d84b;>c4f05e2 [maven-release-plugin] prepare release plexus-interactivity-1.3 https://github.com/codehaus-plexus/plexus-interactivity/commit/ea4900939b82d9e8a812a27e9e870899951003eb;>ea49009 Bump org.jline:jline-reader from 3.25.0 to 3.25.1 https://github.com/codehaus-plexus/plexus-interactivity/commit/1bb7afbc77d523670eaf45c92e7eeabbc769dc70;>1bb7afb Code cleanup to remove dependency to plexus-utils https://github.com/codehaus-plexus/plexus-interactivity/commit/9e9d267ea5fa49c5f201d8fc31c15d27ca16b011;>9e9d267 Upgrade org.jline:jline to 3.25.0 https://github.com/codehaus-plexus/plexus-interactivity/commit/455dc61c1d3c0063ae469a771a7e5b56553134a0;>455dc61 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-interactivity/compare/plexus-interactivity-1.2...plexus-interactivity-1.3;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 [maven-enforcer]
dependabot[bot] closed pull request #302: Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 URL: https://github.com/apache/maven-enforcer/pull/302 -- 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] Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 [maven-enforcer]
dependabot[bot] commented on PR #302: URL: https://github.com/apache/maven-enforcer/pull/302#issuecomment-1927305353 Superseded by #304. -- 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
[PR] Bump org.assertj:assertj-core from 3.25.1 to 3.25.3 [maven-enforcer]
dependabot[bot] opened a new pull request, #304: URL: https://github.com/apache/maven-enforcer/pull/304 Bumps [org.assertj:assertj-core](https://github.com/assertj/assertj) from 3.25.1 to 3.25.3. Release notes Sourced from https://github.com/assertj/assertj/releases;>org.assertj:assertj-core's releases. v.3.25.3 :bug: Bug Fixes Lock maven-clean-plugin version for all modules Core Fix a performance regression in the recursive comparison related to FieldLocation https://redirect.github.com/assertj/assertj/issues/3350;>#3350 Don't fail when the recursive comparison checks compared fields in collection elements https://redirect.github.com/assertj/assertj/issues/3349;>#3349 (proper fix: https://redirect.github.com/assertj/assertj/issues/3354;>#3354) :hammer: Dependency Upgrades Upgrade to Flatten Maven Plugin 1.6.0 https://redirect.github.com/assertj/assertj/issues/3335;>#3335 Upgrade to Groovy 4.0.18 https://redirect.github.com/assertj/assertj/issues/3347;>#3347 Upgrade to Hibernate Core 6.4.2.Final https://redirect.github.com/assertj/assertj/issues/3338;>#3338 Upgrade to Maven Surefire Report Plugin 3.2.5 https://redirect.github.com/assertj/assertj/issues/3330;>#3330 Upgrade to PITest Maven 1.15.6 https://redirect.github.com/assertj/assertj/issues/3348;>#3348 Upgrade to SpotBugs Maven Plugin 4.8.3.0 https://redirect.github.com/assertj/assertj/issues/3336;>#3336 Upgrade to advanced-security/maven-dependency-submission-action to 4 https://redirect.github.com/assertj/assertj/issues/3346;>#3346 :heart: Contributors Thanks to all the contributors who worked on this release: https://github.com/ash211;>@​ash211 v3.25.2 :bug: Bug Fixes Fix unresolvable Javadoc stylesheet URLs, simplify configuration https://redirect.github.com/assertj/assertj/issues/3324;>#3324 Core Fix missing configuration for MatcherAssert soft assertions Make deprecation notice visible in AbstractAssert#asList https://redirect.github.com/assertj/assertj/issues/3327;>#3327 Recursive comparison uses equals on root object when useOverriddenEquals is enabled https://redirect.github.com/assertj/assertj/issues/3320;>#3320 satisfiesExactlyInAnyOrder fails if actual overrides equals https://redirect.github.com/assertj/assertj/issues/3339;>#3339 Avoid calling actual.hashCode() and expected.hashCode() in DualValue https://redirect.github.com/assertj/assertj/issues/3340;>#3340 Recursive comparison checks for existence of fields in types that parameterize nested unordered iterables https://redirect.github.com/assertj/assertj/issues/3332;>#3332 :hammer: Dependency Upgrades Upgrade to EqualsVerifier 3.15.6 https://redirect.github.com/assertj/assertj/issues/3329;>#3329 Upgrade to Maven Surefire Plugin 3.2.5 https://redirect.github.com/assertj/assertj/issues/3328;>#3328 Upgrade to Spotless Maven Plugin 2.43.0 https://redirect.github.com/assertj/assertj/issues/3345;>#3345 :heart: Contributors Thanks to all the contributors who worked on this release: ... (truncated) Commits https://github.com/assertj/assertj/commit/cd72df8cf56e2b7dc6f560cc1066c3643920fe7f;>cd72df8 [maven-release-plugin] prepare release assertj-build-3.25.3 https://github.com/assertj/assertj/commit/c9b3177ad8b133f3b71f95fe94a4f7d9e92d841c;>c9b3177 fix: missing license https://github.com/assertj/assertj/commit/ae62aca8688421652a00b7d8660db30bc4b4a6ad;>ae62aca Ignore containers when checking compared fields existence in the recursive co... https://github.com/assertj/assertj/commit/bad16efa2bdb181983776b71ecbbcf83032609f5;>bad16ef chore(deps-dev): bump org.hibernate.orm:hibernate-core from 6.4.2.Final to 6 https://github.com/assertj/assertj/commit/c7940570d5b3f5743ac221e303733aeb1c0e6527;>c794057 Fix a performance regression in the recursive comparison related to FieldLoca... https://github.com/assertj/assertj/commit/9ecb7f48689f5effaf601f637d9a75a4c5749693;>9ecb7f4 Lock maven-clean-plugin version for all modules https://github.com/assertj/assertj/commit/d42d40c7d2d35fade2c5da6d0a85d2d3bc4e79cf;>d42d40c chore(deps): bump org.pitest:pitest-maven from 1.15.3 to 1.15.6 (https://redirect.github.com/assertj/assertj/issues/3348;>#3348) https://github.com/assertj/assertj/commit/5b32492639129a2cc01864515fe882c224534e20;>5b32492 chore(deps): bump org.apache.maven.plugins:maven-surefire-report-plugin from ... https://github.com/assertj/assertj/commit/e27cc02080179339948a5ec9ca8dabea5abff3dc;>e27cc02 chore(deps): bump org.codehaus.mojo:flatten-maven-plugin from 1.5.0 to 1.6.0 ... https://github.com/assertj/assertj/commit/97710916f7f750d0ee9a8857b978c7393386571c;>9771091 chore(deps): bump com.github.spotbugs:spotbugs-maven-plugin from 4.8.2.0 to 4... Additional commits viewable in
[PR] Bump org.junit:junit-bom from 5.10.1 to 5.10.2 [maven-enforcer]
dependabot[bot] opened a new pull request, #303: URL: https://github.com/apache/maven-enforcer/pull/303 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.10.1 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit:junit-bom's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] [Resolved] (MWRAPPER-121) Specifying an invalid version will make the mvnw script output nothing instead of an error
[
https://issues.apache.org/jira/browse/MWRAPPER-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Marwell resolved MWRAPPER-121.
---
Resolution: Duplicate
> Specifying an invalid version will make the mvnw script output nothing
> instead of an error
> --
>
> Key: MWRAPPER-121
> URL: https://issues.apache.org/jira/browse/MWRAPPER-121
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Affects Versions: 3.2.0
>Reporter: Benjamin Marwell
>Priority: Major
>
> Given the following setup:
> {code}
> mvn wrapper:wrapper -Dmaven=4.0.0-alpha-8 -Dtype=only-script
> {code}
> The output of the created {{./mvnw}} script is empty, because the 404 wget
> error will not be handled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Fix Version/s: 3.9.7
4.0.0
4.0.0-alpha-13
> Maven Core bug regarding resolution scopes for Mojos
>
>
> Key: MNG-8041
> URL: https://issues.apache.org/jira/browse/MNG-8041
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0, 4.0.0-alpha-13
>
>
> This bug affects all released Maven versions.
> Reproducer: [https://github.com/cstamas/MNG-8041]
> Description of the bug: when a Mojo requires Core to collect/resolve given
> ResolutionScope, Maven Core does it wrong. Problem is how
> LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
> plus, how Resolver works. LDR constructs the Resolver filters properly, then
> it calls into DPDR, that performs collection. To achieve that, DPDR *blindly*
> adds all the POM dependencies to Collect request (which is graph root). But
> this is wrong, as this should happen with considering requested (to be
> included or to be excluded) scopes. Next what happens, that when collect
> request is processed by Resolver, it will contain nodes from unwanted scopes
> (as Maven Core blindly added all of them from POM. Also, if Resolver would be
> asked to create root, it would NOT add these in the first place), and due
> that, conflict resolver may possibly eliminate other nodes (as POM ones
> "always wins", are closest to graph root), and also, even the winners will be
> eliminate in subsequent step, for example due scope filtering. This results
> in incomplete resolution scope.
> Consequence: let's consider example where Mojo asks for "runtime" resolution
> scope. To serve this, Maven will add ALL dependencies present in POM to
> collect request (even those in scopes to be omitted, like "test" scoped
> ones), and will perform "collect" with Resolver. When Resolver returns, the
> graph will contain nodes (as 1st level, as they are POM direct
> dependendencies) that MAY be contained in deeper nodes of non-test scoped
> ones (the guice+guava example). Next, "conflict resolution" happens, and
> naturally all the "test" scoped 1st level dependencies "win", rendering
> removal of others. Finally, due "runtime" requested resolution scope, the
> "test" scoped dependencies are (rightfully) filtered out. {*}This obviously
> leads to incomplete runtime build path{*}.
> Or in other words, Maven is wrong here: it adds 1st level dependencies to
> CollectRequest that should not be there in the first place (in example above,
> the "test" scoped ones), that will cause that Resolver "collect" step build a
> graph that has "unwanted" scoped nodes closer to root than actually needed
> runtime dependencies (remember: test nodes will be not affected by filter, as
> they are already present, added by Maven, and test node children are
> collected also as "runtime", just to have "test" scope inherited later in the
> process, hence all the children of "test" node will end up in "test" scope,
> despite "exclude test" is present!), this will cause that in dependency
> conflict resolution step, they will kick out all the rightful runtime
> dependencies, and finally, all these winners are removed due scope filter.
> Implication of this bug is following important fact: the project "runtime"
> resolution scope (as when asked by Mojo) and project "runtime" resolution
> scope (as when used as a dependency on some downstream project) {*}were not
> the same{*}!
> Effects of this bug are explained in "Important Consequences" section of this
> page
> [https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
> (that is wrongly written: all that is a consequence of this bug). Also, have
> to note, that when this bug get addressed, it will NOT render "workarounds"
> broken (ie. introduction of another module just to package "runtime"
> classpath using m-assembly-p or alike plugins), just "obsolete", as packaging
> of runtime dependencies will become possible in-situ (in the same module of
> the project).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due "runtime"
requested resolution scope, the "test" scoped dependencies are (rightfully)
filtered out. {*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
Effects of this bug are explained in "Important Consequences" section of this
page
[https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
(that is wrongly written: all that is a consequence of this bug). Also, have
to note, that when this bug get addressed, it will NOT render "workarounds"
broken (ie. introduction of another module just to package "runtime" classpath
using m-assembly-p or alike plugins), just "obsolete", as packaging of runtime
dependencies will become possible in-situ (in the same module of the project).
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due "runtime"
requested resolution scope, the "test" scoped dependencies are (rightfully)
filtered out. {*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(as when used as a dependency on some downstream project) {*}were not the
same{*}!
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due "runtime"
requested resolution scope, the "test" scoped dependencies are (rightfully)
filtered out. {*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
scope (as when asked by Mojo) and project "runtime" scope (when used as a
dependency on some downstream project) {*}were not the same{*}!
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win",
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due "runtime"
requested resolution scope, the "test" scoped dependencies are (rightfully)
filtered out. {*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
Implication of this bug is following important fact: the project "runtime"
resolution scope (as when asked by Mojo) and project "runtime" resolution scope
(when used as a dependency on some downstream project) {*}were not the same{*}!
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due "runtime"
requested resolution scope, the "test" scoped dependencies are (rightfully)
filtered out. {*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution step, they will kick out all the rightful runtime dependencies, and
finally, all these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due "runtime"
requested resolution scope, the "test" scoped dependencies are (rightfully)
filtered out. {*}This obviously leads to incomplete runtime build path{*}.
Or in
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: [https://github.com/cstamas/MNG-8041]
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due "runtime"
requested resolution scope, the "test" scoped dependencies are (rightfully)
filtered out. {*}This obviously leads to incomplete runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Reproducer: https://github.com/cstamas/MNG-8041
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obviously leads to incomplete runtime
build path{*}.
Or in other words,
[jira] [Comment Edited] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814368#comment-17814368 ] Tamas Cservenak edited comment on MRESOLVER-391 at 2/5/24 1:58 PM: --- Hi all, please see MNG-8041 I think we found a bug in Maven Core: MNG-8041 And this bug causes all the problems described here. was (Author: cstamas): Hi all, please see MNG-8041 I think we found a bug in Maven Core: MNG-8041 > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814368#comment-17814368 ] Tamas Cservenak commented on MRESOLVER-391: --- Hi all, please see MNG-8041 I think we found a bug in Maven Core: MNG-8041 > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > Original issue description was: "As per MNG-5988: if an artifact in "test" > scope is found nearer, but in scope "compile" is found deeper in graph, the > "test" scope wins. This at runtime may lead to CNFEx." > This is completely wrong premise, and it contains following false assumptions: > * The "test" classpath is superset of "runtime" classpath. Is not. > * (derived from that above) To get "runtime" classpath collect via resolver > "test" classpath and cherry-pick non-"test" (or filter out "test") scoped > nodes. This is not how it works. > * A collected graph can contain both, "test" and "runtime" classpath (implied > with "test scope wins but at runtime..."). There is no "production part" of > "test" graph. Graph is this or that, not both, should not be assumed > "overlapping". > When one asks resolver to collect (or resolve), resolver will perform based > on input. And the result is either this or that, but not both. In fact, the > collected "dirty tree" (graph) cannot even represent both "test" or "runtime" > at the same time! > The reproducers in this issue are actually precise examples showing why it is > impossible. > Hence, this issue should be more like a "discussion" to decide what is right > behavior of resolver in these cases, as for sure there are some edge cases > (like silent version bump from 1.x to 2.x), but still, it does happen per > user instruction (who authors POM), and Resolver does not want to delve into > "compatibility calculation" space, where it can decide is a change > "compatible" or not (like semver and alike). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Reproducer: https://github.com/cstamas/MNG-8041
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obviously leads to incomplete runtime
build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obviously leads to incomplete runtime
build path{*}.
Or in other words, Maven is wrong here: it adds 1st level
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "runtime" resolution
scope. To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (as 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obviously leads to incomplete runtime
build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (as 1st level, as they are POM direct dependendencies)
that MAY be contained in deeper nodes of non-test scoped ones (the guice+guava
example). Next, "conflict resolution" happens, and naturally all the "test"
scoped 1st level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obviously leads to incomplete
compile+runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (as 1st level, as they are POM direct dependendencies)
that MAY be contained in deeper nodes of non-test scoped ones (the guice+guava
example). Next, "conflict resolution" happens, and naturally all the "test"
scoped 1st level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obviously leads to incomplete
compile+runtime build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (as 1st level, as they are POM direct dependendencies)
that MAY be contained in deeper nodes of non-test scoped ones (the guice+guava
example). Next, "conflict resolution" happens, and naturally all the "test"
scoped 1st level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obviously leads to incomplete runtime
build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (as 1st level, as they are POM direct dependendencies)
that MAY be contained in deeper nodes of non-test scoped ones (the guice+guava
example). Next, "conflict resolution" happens, and naturally all the "test"
scoped 1st level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obviously leads to incomplete runtime
build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (as 1st level, as they are POM direct dependendencies)
that MAY be contained in deeper nodes of non-test scoped ones (the guice+guava
example). Next, "conflict resolution" happens, and naturally all the "test"
scoped 1st level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obvious leads to incomplete build
path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (as 1st level, as they are POM direct dependendencies)
that MAY be contained in deeper nodes of non-test scoped ones (the guice+guava
example). Next, "conflict resolution" happens, and naturally all the "test"
scoped 1st level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obvious leads to incomplete build
path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request is processed
by Resolver, it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM. Also, if Resolver would be asked to create root, it
would NOT add these in the first place), and due that, conflict resolver may
possibly eliminate other nodes (as POM ones "always wins", are closest to graph
root), and also, even the winners will be eliminate in subsequent step, for
example due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, DPDR *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolve given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, added by Maven, and test node children are collected
also as "runtime", just to have "test" scope inherited later in the process,
hence all the children of "test" node will end up in "test" scope, despite
"exclude test" is present!), this will cause that in dependency conflict
resolution kick out all the rightful runtime dependencies, and finally, all
these winners are removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
Or in other words, Maven is wrong here: it adds 1st level dependencies to
CollectRequest that should not be there in the first place (in example above,
the "test" scoped ones), that will cause that Resolver "collect" step build a
graph that has "unwanted" scoped nodes closer to root than actually needed
runtime dependencies (remember: test nodes will be not affected by filter, as
they are already present, and test node children are collected also as
"runtime", just to have "test" scope inherited later in the process, hence all
the children of "test" node will end up in "test" scope, despite "exclude test"
is present!), this will cause that in dependency conflict resolution kick out
all the rightful runtime dependencies, and finally, all these winners are
removed due scope filter.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
> Maven Core bug regarding resolution scopes for Mojos
>
>
> Key: MNG-8041
>
[jira] [Commented] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814359#comment-17814359
]
ASF GitHub Bot commented on MNG-8041:
-
gnodet commented on code in PR #1398:
URL: https://github.com/apache/maven/pull/1398#discussion_r1478270635
##
maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleDependencyResolver.java:
##
@@ -240,8 +240,11 @@ private Set getDependencies(
scopesToCollect = new HashSet<>(scopesToCollect);
scopesToCollect.addAll(scopesToResolve);
-DependencyFilter collectionFilter = new ScopeDependencyFilter(null,
negate(scopesToCollect));
-DependencyFilter resolutionFilter = new ScopeDependencyFilter(null,
negate(scopesToResolve));
+Collection collectScopesToExclude = negate(scopesToCollect);
+Collection resolveScopesToExclude = negate(scopesToResolve);
+
+DependencyFilter collectionFilter = new ScopeDependencyFilter(null,
collectScopesToExclude);
+DependencyFilter resolutionFilter = new ScopeDependencyFilter(null,
resolveScopesToExclude);
Review Comment:
can we just use the scopes to collect / resolve instead of the ones to
exclude and give them as a negative test in the filter ?
i.e.:
```
DependencyFilter collectionFilter = new
ScopeDependencyFilter(scopesToCollect);
DependencyFilter resolutionFilter = new
ScopeDependencyFilter(scopesToResolve);
```
> Maven Core bug regarding resolution scopes for Mojos
>
>
> Key: MNG-8041
> URL: https://issues.apache.org/jira/browse/MNG-8041
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
>
> This bug affects all released Maven versions.
> Description of the bug: when a Mojo requires Core to collect/resolver given
> ResolutionScope, Maven Core does it wrong. Problem is how
> LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
> plus, how Resolver works. LDR constructs the Resolver filters properly, then
> it calls into DPDR, that performs collection. To achieve that, it *blindly*
> adds all the POM dependencies to Collect request (which is graph root). But
> this is wrong, as this should happen with considering requested (to be
> included or to be excluded) scopes. Next what happens, that when collect
> request processed by Resolver it will contain nodes from unwanted scopes (as
> Maven Core blindly added all of them from POM, if Resolver would be asked to
> create root, it would NOT add these in the first place), and due that,
> conflict resolver may possibly eliminate other nodes (as POM ones "always
> wins", are closest to graph root), and also, even the winners will be
> eliminate in subsequent step, for example due scope filtering. This results
> in incomplete resolution scope.
> Consequence: let's consider example where Mojo asks for "compile+runtime"
> resolution scope. To serve this, Maven will add ALL dependencies present in
> POM to collect request (even those in scopes to be omitted, like "test"
> scoped ones), and will perform "collect" with Resolver. When Resolver
> returns, the graph will contain nodes (and 1st level, as they are POM direct
> dependendencies) that MAY be contained in deeper nodes of non-test scoped
> ones (the guice+guava example). Next, "conflict resolution" happens, and
> naturally all the "test" scoped 1st level dependencies "win", rendering
> removal of others. Finally, due "compile+runtime" requested resolution scope,
> the "test" scoped dependencies are (rightfully) filtered out. {*}This obvious
> leads to incomplete build path{*}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8041] A quick draft about problem [maven]
gnodet commented on code in PR #1398: URL: https://github.com/apache/maven/pull/1398#discussion_r1478270635 ## maven-core/src/main/java/org/apache/maven/lifecycle/internal/LifecycleDependencyResolver.java: ## @@ -240,8 +240,11 @@ private Set getDependencies( scopesToCollect = new HashSet<>(scopesToCollect); scopesToCollect.addAll(scopesToResolve); -DependencyFilter collectionFilter = new ScopeDependencyFilter(null, negate(scopesToCollect)); -DependencyFilter resolutionFilter = new ScopeDependencyFilter(null, negate(scopesToResolve)); +Collection collectScopesToExclude = negate(scopesToCollect); +Collection resolveScopesToExclude = negate(scopesToResolve); + +DependencyFilter collectionFilter = new ScopeDependencyFilter(null, collectScopesToExclude); +DependencyFilter resolutionFilter = new ScopeDependencyFilter(null, resolveScopesToExclude); Review Comment: can we just use the scopes to collect / resolve instead of the ones to exclude and give them as a negative test in the filter ? i.e.: ``` DependencyFilter collectionFilter = new ScopeDependencyFilter(scopesToCollect); DependencyFilter resolutionFilter = new ScopeDependencyFilter(scopesToResolve); ``` -- 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
[PR] Bump org.junit:junit-bom from 5.10.1 to 5.10.2 [maven-antrun-plugin]
dependabot[bot] opened a new pull request, #92: URL: https://github.com/apache/maven-antrun-plugin/pull/92 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.10.1 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit:junit-bom's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider example where Mojo asks for "compile+runtime"
resolution scope. To serve this, Maven will add ALL dependencies present in POM
to collect request (even those in scopes to be omitted, like "test" scoped
ones), and will perform "collect" with Resolver. When Resolver returns, the
graph will contain nodes (and 1st level, as they are POM direct
dependendencies) that MAY be contained in deeper nodes of non-test scoped ones
(the guice+guava example). Next, "conflict resolution" happens, and naturally
all the "test" scoped 1st level dependencies "win", rendering removal of
others. Finally, due "compile+runtime" requested resolution scope, the "test"
scoped dependencies are (rightfully) filtered out. {*}This obvious leads to
incomplete build path{*}.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider Mojo asks for "compile+runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (and 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obvious leads to incomplete build
path{*}.
> Maven Core bug regarding resolution scopes for Mojos
>
>
> Key: MNG-8041
> URL: https://issues.apache.org/jira/browse/MNG-8041
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
>
> This bug affects all released Maven versions.
> Description of the bug: when a Mojo requires Core to collect/resolver given
> ResolutionScope, Maven Core does it wrong. Problem is how
> LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
> plus, how Resolver works. LDR constructs the Resolver filters properly, then
> it calls into DPDR, that performs collection. To achieve that, it *blindly*
> adds all the POM dependencies to Collect request (which is graph root). But
> this is wrong, as this should happen with considering requested
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Description:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
Consequence: let's consider Mojo asks for "compile+runtime" resolution scope.
To serve this, Maven will add ALL dependencies present in POM to collect
request (even those in scopes to be omitted, like "test" scoped ones), and will
perform "collect" with Resolver. When Resolver returns, the graph will contain
nodes (and 1st level, as they are POM direct dependendencies) that MAY be
contained in deeper nodes of non-test scoped ones (the guice+guava example).
Next, "conflict resolution" happens, and naturally all the "test" scoped 1st
level dependencies "win", rendering removal of others. Finally, due
"compile+runtime" requested resolution scope, the "test" scoped dependencies
are (rightfully) filtered out. {*}This obvious leads to incomplete build
path{*}.
was:
This bug affects all released Maven versions.
Description of the bug: when a Mojo requires Core to collect/resolver given
ResolutionScope, Maven Core does it wrong. Problem is how
LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
plus, how Resolver works. LDR constructs the Resolver filters properly, then it
calls into DPDR, that performs collection. To achieve that, it *blindly* adds
all the POM dependencies to Collect request (which is graph root). But this is
wrong, as this should happen with considering requested (to be included or to
be excluded) scopes. Next what happens, that when collect request processed by
Resolver it will contain nodes from unwanted scopes (as Maven Core blindly
added all of them from POM, if Resolver would be asked to create root, it would
NOT add these in the first place), and due that, conflict resolver may possibly
eliminate other nodes (as POM ones "always wins", are closest to graph root),
and also, even the winners will be eliminate in subsequent step, for example
due scope filtering. This results in incomplete resolution scope.
> Maven Core bug regarding resolution scopes for Mojos
>
>
> Key: MNG-8041
> URL: https://issues.apache.org/jira/browse/MNG-8041
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
>
> This bug affects all released Maven versions.
> Description of the bug: when a Mojo requires Core to collect/resolver given
> ResolutionScope, Maven Core does it wrong. Problem is how
> LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
> plus, how Resolver works. LDR constructs the Resolver filters properly, then
> it calls into DPDR, that performs collection. To achieve that, it *blindly*
> adds all the POM dependencies to Collect request (which is graph root). But
> this is wrong, as this should happen with considering requested (to be
> included or to be excluded) scopes. Next what happens, that when collect
> request processed by Resolver it will contain nodes from unwanted scopes (as
> Maven Core blindly added all of them from POM, if Resolver would be asked to
> create root, it would NOT add these in the first place), and due that,
> conflict resolver may possibly eliminate other nodes (as POM ones "always
> wins", are closest to graph root), and also, even the winners will be
> eliminate in subsequent step, for example due scope filtering. This results
> in incomplete resolution scope.
> Consequence: let's consider Mojo asks for "compile+runtime" resolution scope.
> To serve this, Maven will add ALL dependencies present in POM to collect
> request (even those in scopes to be omitted, like
Re: [PR] Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 [maven-plugin-tools]
dependabot[bot] closed pull request #258: Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 URL: https://github.com/apache/maven-plugin-tools/pull/258 -- 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] Bump org.assertj:assertj-core from 3.25.1 to 3.25.2 [maven-plugin-tools]
dependabot[bot] commented on PR #258: URL: https://github.com/apache/maven-plugin-tools/pull/258#issuecomment-1927027294 Superseded by #262. -- 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
[PR] Bump org.assertj:assertj-core from 3.25.1 to 3.25.3 [maven-plugin-tools]
dependabot[bot] opened a new pull request, #262: URL: https://github.com/apache/maven-plugin-tools/pull/262 Bumps [org.assertj:assertj-core](https://github.com/assertj/assertj) from 3.25.1 to 3.25.3. Release notes Sourced from https://github.com/assertj/assertj/releases;>org.assertj:assertj-core's releases. v.3.25.3 :bug: Bug Fixes Lock maven-clean-plugin version for all modules Core Fix a performance regression in the recursive comparison related to FieldLocation https://redirect.github.com/assertj/assertj/issues/3350;>#3350 Don't fail when the recursive comparison checks compared fields in collection elements https://redirect.github.com/assertj/assertj/issues/3349;>#3349 (proper fix: https://redirect.github.com/assertj/assertj/issues/3354;>#3354) :hammer: Dependency Upgrades Upgrade to Flatten Maven Plugin 1.6.0 https://redirect.github.com/assertj/assertj/issues/3335;>#3335 Upgrade to Groovy 4.0.18 https://redirect.github.com/assertj/assertj/issues/3347;>#3347 Upgrade to Hibernate Core 6.4.2.Final https://redirect.github.com/assertj/assertj/issues/3338;>#3338 Upgrade to Maven Surefire Report Plugin 3.2.5 https://redirect.github.com/assertj/assertj/issues/3330;>#3330 Upgrade to PITest Maven 1.15.6 https://redirect.github.com/assertj/assertj/issues/3348;>#3348 Upgrade to SpotBugs Maven Plugin 4.8.3.0 https://redirect.github.com/assertj/assertj/issues/3336;>#3336 Upgrade to advanced-security/maven-dependency-submission-action to 4 https://redirect.github.com/assertj/assertj/issues/3346;>#3346 :heart: Contributors Thanks to all the contributors who worked on this release: https://github.com/ash211;>@​ash211 v3.25.2 :bug: Bug Fixes Fix unresolvable Javadoc stylesheet URLs, simplify configuration https://redirect.github.com/assertj/assertj/issues/3324;>#3324 Core Fix missing configuration for MatcherAssert soft assertions Make deprecation notice visible in AbstractAssert#asList https://redirect.github.com/assertj/assertj/issues/3327;>#3327 Recursive comparison uses equals on root object when useOverriddenEquals is enabled https://redirect.github.com/assertj/assertj/issues/3320;>#3320 satisfiesExactlyInAnyOrder fails if actual overrides equals https://redirect.github.com/assertj/assertj/issues/3339;>#3339 Avoid calling actual.hashCode() and expected.hashCode() in DualValue https://redirect.github.com/assertj/assertj/issues/3340;>#3340 Recursive comparison checks for existence of fields in types that parameterize nested unordered iterables https://redirect.github.com/assertj/assertj/issues/3332;>#3332 :hammer: Dependency Upgrades Upgrade to EqualsVerifier 3.15.6 https://redirect.github.com/assertj/assertj/issues/3329;>#3329 Upgrade to Maven Surefire Plugin 3.2.5 https://redirect.github.com/assertj/assertj/issues/3328;>#3328 Upgrade to Spotless Maven Plugin 2.43.0 https://redirect.github.com/assertj/assertj/issues/3345;>#3345 :heart: Contributors Thanks to all the contributors who worked on this release: ... (truncated) Commits https://github.com/assertj/assertj/commit/cd72df8cf56e2b7dc6f560cc1066c3643920fe7f;>cd72df8 [maven-release-plugin] prepare release assertj-build-3.25.3 https://github.com/assertj/assertj/commit/c9b3177ad8b133f3b71f95fe94a4f7d9e92d841c;>c9b3177 fix: missing license https://github.com/assertj/assertj/commit/ae62aca8688421652a00b7d8660db30bc4b4a6ad;>ae62aca Ignore containers when checking compared fields existence in the recursive co... https://github.com/assertj/assertj/commit/bad16efa2bdb181983776b71ecbbcf83032609f5;>bad16ef chore(deps-dev): bump org.hibernate.orm:hibernate-core from 6.4.2.Final to 6 https://github.com/assertj/assertj/commit/c7940570d5b3f5743ac221e303733aeb1c0e6527;>c794057 Fix a performance regression in the recursive comparison related to FieldLoca... https://github.com/assertj/assertj/commit/9ecb7f48689f5effaf601f637d9a75a4c5749693;>9ecb7f4 Lock maven-clean-plugin version for all modules https://github.com/assertj/assertj/commit/d42d40c7d2d35fade2c5da6d0a85d2d3bc4e79cf;>d42d40c chore(deps): bump org.pitest:pitest-maven from 1.15.3 to 1.15.6 (https://redirect.github.com/assertj/assertj/issues/3348;>#3348) https://github.com/assertj/assertj/commit/5b32492639129a2cc01864515fe882c224534e20;>5b32492 chore(deps): bump org.apache.maven.plugins:maven-surefire-report-plugin from ... https://github.com/assertj/assertj/commit/e27cc02080179339948a5ec9ca8dabea5abff3dc;>e27cc02 chore(deps): bump org.codehaus.mojo:flatten-maven-plugin from 1.5.0 to 1.6.0 ... https://github.com/assertj/assertj/commit/97710916f7f750d0ee9a8857b978c7393386571c;>9771091 chore(deps): bump com.github.spotbugs:spotbugs-maven-plugin from 4.8.2.0 to 4... Additional commits viewable in
[PR] Bump org.junit:junit-bom from 5.10.1 to 5.10.2 [maven-plugin-tools]
dependabot[bot] opened a new pull request, #261: URL: https://github.com/apache/maven-plugin-tools/pull/261 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.10.1 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit:junit-bom's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[ https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8041: - Description: This bug affects all released Maven versions. Description of the bug: when a Mojo requires Core to collect/resolver given ResolutionScope, Maven Core does it wrong. Problem is how LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate plus, how Resolver works. LDR constructs the Resolver filters properly, then it calls into DPDR, that performs collection. To achieve that, it *blindly* adds all the POM dependencies to Collect request (which is graph root). But this is wrong, as this should happen with considering requested (to be included or to be excluded) scopes. Next what happens, that when collect request processed by Resolver it will contain nodes from unwanted scopes (as Maven Core blindly added all of them from POM, if Resolver would be asked to create root, it would NOT add these in the first place), and due that, conflict resolver may possibly eliminate other nodes (as POM ones "always wins", are closest to graph root), and also, even the winners will be eliminate in subsequent step, for example due scope filtering. This results in incomplete resolution scope. was: This bug affects all released Maven versions. Description of the bug: when a Mojo requires Core to collect/resolver given ResolutionScope, Maven Core does it wrong. Problem is how LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate plus, how Resolver works. LDR constructs the Resolver filters properly, then it calls into DPDR, that performs collection. To achieve that, it **blindly** adds all the dependencies to Collect request (graph root). But this is wrong, as this should happen with considering requested (to be included or to be excluded) scopes. Next what happens, that when collect request processed by Resolver it will contain nodes from unwanted scopes (as Maven Core blindly added all of them from POM), and due that, conflict resolver may possibly eliminate other nodes (as POM ones "always wins", are closest to graph root), and also, even the winners will be eliminate in subsequent step, for example due scope filtering. This results in incomplete resolution scope. > Maven Core bug regarding resolution scopes for Mojos > > > Key: MNG-8041 > URL: https://issues.apache.org/jira/browse/MNG-8041 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > > This bug affects all released Maven versions. > Description of the bug: when a Mojo requires Core to collect/resolver given > ResolutionScope, Maven Core does it wrong. Problem is how > LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate > plus, how Resolver works. LDR constructs the Resolver filters properly, then > it calls into DPDR, that performs collection. To achieve that, it *blindly* > adds all the POM dependencies to Collect request (which is graph root). But > this is wrong, as this should happen with considering requested (to be > included or to be excluded) scopes. Next what happens, that when collect > request processed by Resolver it will contain nodes from unwanted scopes (as > Maven Core blindly added all of them from POM, if Resolver would be asked to > create root, it would NOT add these in the first place), and due that, > conflict resolver may possibly eliminate other nodes (as POM ones "always > wins", are closest to graph root), and also, even the winners will be > eliminate in subsequent step, for example due scope filtering. This results > in incomplete resolution scope. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[ https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8041: - Description: This bug affects all released Maven versions. Description of the bug: when a Mojo requires Core to collect/resolver given ResolutionScope, Maven Core does it wrong. Problem is how LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate plus, how Resolver works. LDR constructs the Resolver filters properly, then it calls into DPDR, that performs collection. To achieve that, it **blindly** adds all the dependencies to Collect request (graph root). But this is wrong, as this should happen with considering requested (to be included or to be excluded) scopes. Next what happens, that when collect request processed by Resolver it will contain nodes from unwanted scopes (as Maven Core blindly added all of them from POM), and due that, conflict resolver may possibly eliminate other nodes (as POM ones "always wins", are closest to graph root), and also, even the winners will be eliminate in subsequent step, for example due scope filtering. This results in incomplete resolution scope. was: This bug affects all released Maven versions. Description of the bug: when a Mojo requires Core to collect/resolver given ResolutionScope, Maven Core does it wrong. > Maven Core bug regarding resolution scopes for Mojos > > > Key: MNG-8041 > URL: https://issues.apache.org/jira/browse/MNG-8041 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > > This bug affects all released Maven versions. > Description of the bug: when a Mojo requires Core to collect/resolver given > ResolutionScope, Maven Core does it wrong. Problem is how > LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate > plus, how Resolver works. LDR constructs the Resolver filters properly, then > it calls into DPDR, that performs collection. To achieve that, it **blindly** > adds all the dependencies to Collect request (graph root). But this is wrong, > as this should happen with considering requested (to be included or to be > excluded) scopes. Next what happens, that when collect request processed by > Resolver it will contain nodes from unwanted scopes (as Maven Core blindly > added all of them from POM), and due that, conflict resolver may possibly > eliminate other nodes (as POM ones "always wins", are closest to graph root), > and also, even the winners will be eliminate in subsequent step, for example > due scope filtering. This results in incomplete resolution scope. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[ https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8041: - Description: This bug affects all released Maven versions. Description of the bug: when a Mojo requires Core to collect/resolver given ResolutionScope, Maven Core does it wrong. was:This bug, if am right, affects all released Maven versions. > Maven Core bug regarding resolution scopes for Mojos > > > Key: MNG-8041 > URL: https://issues.apache.org/jira/browse/MNG-8041 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > > This bug affects all released Maven versions. > Description of the bug: when a Mojo requires Core to collect/resolver given > ResolutionScope, Maven Core does it wrong. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump org.junit:junit-bom from 5.10.1 to 5.10.2 [maven-doxia]
dependabot[bot] opened a new pull request, #199: URL: https://github.com/apache/maven-doxia/pull/199 Bumps [org.junit:junit-bom](https://github.com/junit-team/junit5) from 5.10.1 to 5.10.2. Release notes Sourced from https://github.com/junit-team/junit5/releases;>org.junit:junit-bom's releases. JUnit 5.10.2 = Platform 1.10.2 + Jupiter 5.10.2 + Vintage 5.10.2 See http://junit.org/junit5/docs/5.10.2/release-notes/;>Release Notes. Full Changelog: https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2 Commits https://github.com/junit-team/junit5/commit/4c0dddad1b96d4a20e92a2cd583954643ac56ac0;>4c0ddda Release 5.10.2 https://github.com/junit-team/junit5/commit/463a14773d884f2bf31f073a87bef9d0938872db;>463a147 Finalize release notes for 5.10.2 https://github.com/junit-team/junit5/commit/43c105a246c0130d08145335cb9986236e2a8465;>43c105a Revert Apply method predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/63d464d1e10a62743fe4024436ef1e006a89df72;>63d464d Revert Harmonize application of method and field filters in search algorithms https://github.com/junit-team/junit5/commit/85ec2fccb32a51fbe6ff966e25726c94a67dd418;>85ec2fc Revert Apply field predicate before searching type hierarchy https://github.com/junit-team/junit5/commit/6209006a7693dbf6f680a5ac4541aba86c9da899;>6209006 Update release notes https://github.com/junit-team/junit5/commit/5ee499f0e0029dbd1120ecf889bd214e2082c589;>5ee499f Fix CI build https://github.com/junit-team/junit5/commit/d919ba71ea4c3b1e60f2d21473ba31ff0f6857ab;>d919ba7 Namespace user-specific build parameters https://github.com/junit-team/junit5/commit/e26cd83ed307ef100399ced9985f04612931984b;>e26cd83 Prepare release notes for 5.10.2 https://github.com/junit-team/junit5/commit/ec8d4282c60f480d3de264330b37e75b1b8d05d9;>ec8d428 Include LauncherInterceptor in launcher module declaration Additional commits viewable in https://github.com/junit-team/junit5/compare/r5.10.1...r5.10.2;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[ https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814335#comment-17814335 ] ASF GitHub Bot commented on MNG-8041: - cstamas opened a new pull request, #1398: URL: https://github.com/apache/maven/pull/1398 This is just a attempt to fix reproducer, and to see what ITs have to say. --- https://issues.apache.org/jira/browse/MNG-8041 > Maven Core bug regarding resolution scopes for Mojos > > > Key: MNG-8041 > URL: https://issues.apache.org/jira/browse/MNG-8041 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Priority: Major > > This bug, if am right, affects all released Maven versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1934) Ability to disable system-out/system-err for successfuly passed tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814333#comment-17814333 ] ASF GitHub Bot commented on SUREFIRE-1934: -- zabetak commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1926867704 Hey @michael-o, according to [a previous comment](https://github.com/apache/maven-surefire/pull/670#issuecomment-1863815281) it seems that the intention of @NissMoony was to provide an option for suppressing all output (irrespective of the type of the result) from the XML report. For our use-case (Apache Hive), I think that disabling all output from the **XML report** is sufficient to move our upgrade further assuming that `redirectTestOutputToFile` option works as before and will still send the STDOUT to a file irrespective of the the changes introduced by this PR. Having more fine grained configurations (e.g., only apply this on successful/failed tests) may be a nice to have feature but not a strong requirement from our side at this point. We all understand that complex configurations are hard to maintain. > Ability to disable system-out/system-err for successfuly passed tests > - > > Key: SUREFIRE-1934 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1934 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 >Reporter: Andrey Turbanov >Priority: Major > > After SUREFIRE-1744 surefire-plugin always reports system-out/system-err even > for successfully passed test. A lot of old projects with big amount of tests > now have to deal with huge output. > I think there should be option to disable new behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-1934] Ability to disable system-out/system-err for successfuly passed tests. [maven-surefire]
zabetak commented on PR #670: URL: https://github.com/apache/maven-surefire/pull/670#issuecomment-1926867704 Hey @michael-o, according to [a previous comment](https://github.com/apache/maven-surefire/pull/670#issuecomment-1863815281) it seems that the intention of @NissMoony was to provide an option for suppressing all output (irrespective of the type of the result) from the XML report. For our use-case (Apache Hive), I think that disabling all output from the **XML report** is sufficient to move our upgrade further assuming that `redirectTestOutputToFile` option works as before and will still send the STDOUT to a file irrespective of the the changes introduced by this PR. Having more fine grained configurations (e.g., only apply this on successful/failed tests) may be a nice to have feature but not a strong requirement from our side at this point. We all understand that complex configurations are hard to maintain. -- 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] [Created] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
Tamas Cservenak created MNG-8041: Summary: Maven Core bug regarding resolution scopes for Mojos Key: MNG-8041 URL: https://issues.apache.org/jira/browse/MNG-8041 Project: Maven Issue Type: Bug Components: Artifacts and Repositories Reporter: Tamas Cservenak This bug, if am right, affects all released Maven versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8026) Maven should define from ground up scopes used with Resolver
[ https://issues.apache.org/jira/browse/MNG-8026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814306#comment-17814306 ] ASF GitHub Bot commented on MNG-8026: - cstamas commented on PR #1391: URL: https://github.com/apache/maven/pull/1391#issuecomment-1926632787 Looks good! Sorry to be late to party, but we can improve all this "on the go" anyway... > Maven should define from ground up scopes used with Resolver > > > Key: MNG-8026 > URL: https://issues.apache.org/jira/browse/MNG-8026 > Project: Maven > Issue Type: Task >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-13 > > > See MRESOLVER-471, it is actually role of Maven (as a resolver consumer > project) to define all these things: > * supported scopes > * transformations of scopes to build path scopes > * fine tune conflict resolution and related things (in session) -- This message was sent by Atlassian Jira (v8.20.10#820010)
