[jira] [Created] (MNG-7443) Consistent logging between optional projects and optional profiles
Giovanni van der Schelde created MNG-7443: - Summary: Consistent logging between optional projects and optional profiles Key: MNG-7443 URL: https://issues.apache.org/jira/browse/MNG-7443 Project: Maven Issue Type: Improvement Components: Core, Logging Affects Versions: 4.0.0-alpha-1 Reporter: Giovanni van der Schelde Maven 4 introduces optional profiles and optional projects. However, the feedback provided to the user on whether a project or profile has been skipped is inconsistent between the two (see image attached). For profiles, it will be logged twice: before and after the build. For projects, it will be logged once: before the build. The idea would be to log the information for skipped optional projects after the build as well. !image-2022-03-21-21-50-55-930.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MNG-7437) Optional profiles that are not found logs warning twice
[ https://issues.apache.org/jira/browse/MNG-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders closed MNG-7437. Fix Version/s: (was: wontfix-candidate) Resolution: Won't Fix > Optional profiles that are not found logs warning twice > --- > > Key: MNG-7437 > URL: https://issues.apache.org/jira/browse/MNG-7437 > Project: Maven > Issue Type: Bug > Components: Command Line, Core, Logging >Affects Versions: 4.0.0-alpha-1 >Reporter: Giovanni van der Schelde >Priority: Minor > Attachments: image-2022-03-21-21-50-55-930.png > > > Maven 4 (MNG-7051) introduced optional profiles, and if such profile could > not be found, the build continues and logs a warning. > Whenever I run this command I noticed the warning is logged twice. Once > before the build and once after the build. This seems unnecessary and is > inconsistent with the behaviour of optional projects. > !image-2022-03-21-21-50-55-930.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7443) Consistent logging between optional projects and optional profiles
[ https://issues.apache.org/jira/browse/MNG-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giovanni van der Schelde updated MNG-7443: -- Description: Maven 4 introduces optional profiles and optional projects. However, the feedback provided to the user on whether a project or profile has been skipped is inconsistent between the two (see image attached). For profiles, it will be logged twice: before and after the build. For projects, it will be logged once: before the build. The idea would be to log the information for skipped optional projects after the build as well. was: Maven 4 introduces optional profiles and optional projects. However, the feedback provided to the user on whether a project or profile has been skipped is inconsistent between the two (see image attached). For profiles, it will be logged twice: before and after the build. For projects, it will be logged once: before the build. The idea would be to log the information for skipped optional projects after the build as well. !image-2022-03-21-21-50-55-930.png! > Consistent logging between optional projects and optional profiles > -- > > Key: MNG-7443 > URL: https://issues.apache.org/jira/browse/MNG-7443 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Affects Versions: 4.0.0-alpha-1 >Reporter: Giovanni van der Schelde >Priority: Minor > Attachments: example.png > > > Maven 4 introduces optional profiles and optional projects. However, the > feedback provided to the user on whether a project or profile has been > skipped is inconsistent between the two (see image attached). > For profiles, it will be logged twice: before and after the build. > For projects, it will be logged once: before the build. > The idea would be to log the information for skipped optional projects after > the build as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7443) Consistent logging between optional projects and optional profiles
[ https://issues.apache.org/jira/browse/MNG-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giovanni van der Schelde updated MNG-7443: -- Attachment: example.png > Consistent logging between optional projects and optional profiles > -- > > Key: MNG-7443 > URL: https://issues.apache.org/jira/browse/MNG-7443 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Affects Versions: 4.0.0-alpha-1 >Reporter: Giovanni van der Schelde >Priority: Minor > Attachments: example.png > > > Maven 4 introduces optional profiles and optional projects. However, the > feedback provided to the user on whether a project or profile has been > skipped is inconsistent between the two (see image attached). > For profiles, it will be logged twice: before and after the build. > For projects, it will be logged once: before the build. > The idea would be to log the information for skipped optional projects after > the build as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7443) Consistent logging between optional projects and optional profiles
[ https://issues.apache.org/jira/browse/MNG-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giovanni van der Schelde updated MNG-7443: -- Description: Maven 4 introduces optional profiles and optional projects. However, the feedback provided to the user on whether a project or profile has been skipped is inconsistent between the two (see image attached). For profiles, it will be logged twice: before and after the build. For projects, it will be logged once: before the build. The idea would be to log the information for skipped optional projects after the build as well. !example.png! was: Maven 4 introduces optional profiles and optional projects. However, the feedback provided to the user on whether a project or profile has been skipped is inconsistent between the two (see image attached). For profiles, it will be logged twice: before and after the build. For projects, it will be logged once: before the build. The idea would be to log the information for skipped optional projects after the build as well. > Consistent logging between optional projects and optional profiles > -- > > Key: MNG-7443 > URL: https://issues.apache.org/jira/browse/MNG-7443 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Affects Versions: 4.0.0-alpha-1 >Reporter: Giovanni van der Schelde >Priority: Minor > Attachments: example.png > > > Maven 4 introduces optional profiles and optional projects. However, the > feedback provided to the user on whether a project or profile has been > skipped is inconsistent between the two (see image attached). > For profiles, it will be logged twice: before and after the build. > For projects, it will be logged once: before the build. > The idea would be to log the information for skipped optional projects after > the build as well. > !example.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7443) Consistent logging between optional projects and optional profiles
[ https://issues.apache.org/jira/browse/MNG-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giovanni van der Schelde updated MNG-7443: -- Attachment: voorbeeld-maven.png > Consistent logging between optional projects and optional profiles > -- > > Key: MNG-7443 > URL: https://issues.apache.org/jira/browse/MNG-7443 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Affects Versions: 4.0.0-alpha-1 >Reporter: Giovanni van der Schelde >Priority: Minor > Attachments: example.png > > > Maven 4 introduces optional profiles and optional projects. However, the > feedback provided to the user on whether a project or profile has been > skipped is inconsistent between the two (see image attached). > For profiles, it will be logged twice: before and after the build. > For projects, it will be logged once: before the build. > The idea would be to log the information for skipped optional projects after > the build as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7443) Consistent logging between optional projects and optional profiles
[ https://issues.apache.org/jira/browse/MNG-7443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giovanni van der Schelde updated MNG-7443: -- Attachment: (was: voorbeeld-maven.png) > Consistent logging between optional projects and optional profiles > -- > > Key: MNG-7443 > URL: https://issues.apache.org/jira/browse/MNG-7443 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Affects Versions: 4.0.0-alpha-1 >Reporter: Giovanni van der Schelde >Priority: Minor > Attachments: example.png > > > Maven 4 introduces optional profiles and optional projects. However, the > feedback provided to the user on whether a project or profile has been > skipped is inconsistent between the two (see image attached). > For profiles, it will be logged twice: before and after the build. > For projects, it will be logged once: before the build. > The idea would be to log the information for skipped optional projects after > the build as well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 merged pull request #502: [SUREFIRE-1432] trimStackTrace = false by default
Tibor17 merged pull request #502: URL: https://github.com/apache/maven-surefire/pull/502 -- 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-1432) trimStackTrace = false by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1432:
---
Description:
*New description:*
Currently,
*Old description:*
Specify {{StackTraceInterpreterExtension}} abstract class with constructor
parameter {{boolean trim}} and protected getter for {{trim}}. Single public
method {{interpret(context): String}}.
DefaultStackTraceImpl - current implementation that trimmed trace prints only
test class
SmartStackTraceImpl - full trace or the following if trimmed (for error):
java.lang.NullPointerException: msg
o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
o.a.s.m.NestedStackTraceInTheSamePackage
o.a.s.m.NestedStackTraceInTheSamePackage
...
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
(for failure - assertion failed - only this: )
SomeAssertionError: msg
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
Here is brief package displayed or full Java package if totally different from
package in test.
was:
Specify {{StackTraceInterpreterExtension}} abstract class with constructor
parameter {{boolean trim}} and protected getter for {{trim}}. Single public
method {{interpret(context): String}}.
DefaultStackTraceImpl - current implementation that trimmed trace prints only
test class
SmartStackTraceImpl - full trace or the following if trimmed (for error):
java.lang.NullPointerException: msg
o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
o.a.s.m.NestedStackTraceInTheSamePackage
o.a.s.m.NestedStackTraceInTheSamePackage
...
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
(for failure - assertion failed - only this: )
SomeAssertionError: msg
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
Here is brief package displayed or full Java package if totally different from
package in test.
> trimStackTrace = false by default
> -
>
> Key: SUREFIRE-1432
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1432
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *New description:*
> Currently,
> *Old description:*
> Specify {{StackTraceInterpreterExtension}} abstract class with constructor
> parameter {{boolean trim}} and protected getter for {{trim}}. Single public
> method {{interpret(context): String}}.
> DefaultStackTraceImpl - current implementation that trimmed trace prints only
> test class
> SmartStackTraceImpl - full trace or the following if trimmed (for error):
> java.lang.NullPointerException: msg
> o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
> o.a.s.m.NestedStackTraceInTheSamePackage
> o.a.s.m.NestedStackTraceInTheSamePackage
> ...
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> (for failure - assertion failed - only this: )
> SomeAssertionError: msg
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> Here is brief package displayed or full Java package if totally different
> from package in test.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1432) trimStackTrace = false by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1432:
---
Description:
*New description:*
Currently, the default value _trimStackTrace_ is set to _true_. This fix
changes the default value.
*Old description:*
Specify {{StackTraceInterpreterExtension}} abstract class with constructor
parameter {{boolean trim}} and protected getter for {{trim}}. Single public
method {{interpret(context): String}}.
DefaultStackTraceImpl - current implementation that trimmed trace prints only
test class
SmartStackTraceImpl - full trace or the following if trimmed (for error):
java.lang.NullPointerException: msg
o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
o.a.s.m.NestedStackTraceInTheSamePackage
o.a.s.m.NestedStackTraceInTheSamePackage
...
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
(for failure - assertion failed - only this: )
SomeAssertionError: msg
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
Here is brief package displayed or full Java package if totally different from
package in test.
was:
*New description:*
Currently,
*Old description:*
Specify {{StackTraceInterpreterExtension}} abstract class with constructor
parameter {{boolean trim}} and protected getter for {{trim}}. Single public
method {{interpret(context): String}}.
DefaultStackTraceImpl - current implementation that trimmed trace prints only
test class
SmartStackTraceImpl - full trace or the following if trimmed (for error):
java.lang.NullPointerException: msg
o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
o.a.s.m.NestedStackTraceInTheSamePackage
o.a.s.m.NestedStackTraceInTheSamePackage
...
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
(for failure - assertion failed - only this: )
SomeAssertionError: msg
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
Here is brief package displayed or full Java package if totally different from
package in test.
> trimStackTrace = false by default
> -
>
> Key: SUREFIRE-1432
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1432
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *New description:*
> Currently, the default value _trimStackTrace_ is set to _true_. This fix
> changes the default value.
> *Old description:*
> Specify {{StackTraceInterpreterExtension}} abstract class with constructor
> parameter {{boolean trim}} and protected getter for {{trim}}. Single public
> method {{interpret(context): String}}.
> DefaultStackTraceImpl - current implementation that trimmed trace prints only
> test class
> SmartStackTraceImpl - full trace or the following if trimmed (for error):
> java.lang.NullPointerException: msg
> o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
> o.a.s.m.NestedStackTraceInTheSamePackage
> o.a.s.m.NestedStackTraceInTheSamePackage
> ...
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> (for failure - assertion failed - only this: )
> SomeAssertionError: msg
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> Here is brief package displayed or full Java package if totally different
> from package in test.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1432) trimStackTrace = false by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1432:
---
Description:
*New description:*
Currently, the default value of the config parameter _trimStackTrace_ is set to
_true_. This fix changes the default value.
*Old description:*
Specify {{StackTraceInterpreterExtension}} abstract class with constructor
parameter {{boolean trim}} and protected getter for {{trim}}. Single public
method {{interpret(context): String}}.
DefaultStackTraceImpl - current implementation that trimmed trace prints only
test class
SmartStackTraceImpl - full trace or the following if trimmed (for error):
java.lang.NullPointerException: msg
o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
o.a.s.m.NestedStackTraceInTheSamePackage
o.a.s.m.NestedStackTraceInTheSamePackage
...
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
(for failure - assertion failed - only this: )
SomeAssertionError: msg
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
Here is brief package displayed or full Java package if totally different from
package in test.
was:
*New description:*
Currently, the default value _trimStackTrace_ is set to _true_. This fix
changes the default value.
*Old description:*
Specify {{StackTraceInterpreterExtension}} abstract class with constructor
parameter {{boolean trim}} and protected getter for {{trim}}. Single public
method {{interpret(context): String}}.
DefaultStackTraceImpl - current implementation that trimmed trace prints only
test class
SmartStackTraceImpl - full trace or the following if trimmed (for error):
java.lang.NullPointerException: msg
o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
o.a.s.m.NestedStackTraceInTheSamePackage
o.a.s.m.NestedStackTraceInTheSamePackage
...
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
(for failure - assertion failed - only this: )
SomeAssertionError: msg
o.a.s.m.SomeTestInSamePackageTest
o.a.s.m.SomeTestInSamePackageTest
Here is brief package displayed or full Java package if totally different from
package in test.
> trimStackTrace = false by default
> -
>
> Key: SUREFIRE-1432
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1432
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *New description:*
> Currently, the default value of the config parameter _trimStackTrace_ is set
> to _true_. This fix changes the default value.
> *Old description:*
> Specify {{StackTraceInterpreterExtension}} abstract class with constructor
> parameter {{boolean trim}} and protected getter for {{trim}}. Single public
> method {{interpret(context): String}}.
> DefaultStackTraceImpl - current implementation that trimmed trace prints only
> test class
> SmartStackTraceImpl - full trace or the following if trimmed (for error):
> java.lang.NullPointerException: msg
> o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
> o.a.s.m.NestedStackTraceInTheSamePackage
> o.a.s.m.NestedStackTraceInTheSamePackage
> ...
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> (for failure - assertion failed - only this: )
> SomeAssertionError: msg
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> Here is brief package displayed or full Java package if totally different
> from package in test.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1525) Exception in a @BeforeClass method in a JUnit suite class does not fail the build if ran in parallel
[
https://issues.apache.org/jira/browse/SUREFIRE-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17513939#comment-17513939
]
Andreya Kostov commented on SUREFIRE-1525:
--
The same behavior is observed when using 3.0.0-M5.
> Exception in a @BeforeClass method in a JUnit suite class does not fail the
> build if ran in parallel
>
>
> Key: SUREFIRE-1525
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1525
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.21.0
>Reporter: Ivan Syarov
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I have a @BeforeClass annotated method in a JUnit test suite class, and if an
> exception is thrown in the method, the parallel build either succeeds if the
> *-DfailIfNoTests* parameter is set to false or fails with "No tests were
> executed" if the parameter is set to true. If the build is started without
> the *parallel* parameter it fails as it should.
> I used a simple project setup to reproduce. I have two test classes, each
> with one test method and a suite class:
> *TestA.class*
> {code:java}
> public class TestA {
> @Test
> public void test() {
> System.out.println("TestA");
> }
> }
> {code}
> *TestB.class*
> {code:java}
> public class TestB {
> @Test
> public void test() {
> System.out.println("TestB");
> }
> }
> {code}
> *TestSuite.class*
> {code:java}
> @RunWith(Suite.class)
> @SuiteClasses({TestA.class, TestB.class})
> public class TestSuite {
> @BeforeClass
> public static void setUp() {
> throw new RuntimeException("ex");
> }
> }
> {code}
> If i execute:
> mvn clean install -Dtest=TestSuite -Dparallel=classes -DthreadCount=2
> -DfailIfNoTests=false
> the build succeeds. If I omit the -DfailIfNoTests=false the build fails, but
> not because of the thrown exception, but with "No tests were executed!". If i
> omit the parallel parameter the build fails appropriately with "There are
> test failures."
> The JUnit version is 4.12
> The surefire plugin version is 2.19.1 - 2.21.0
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #500: [SUREFIRE-2024] Replace testng-junit5 by testng-engine
Tibor17 commented on pull request #500: URL: https://github.com/apache/maven-surefire/pull/500#issuecomment-1081618294 In the old revision of `com.github.testng-team:testng-junit5`, the exclusion was because the TestNG team released only one version of the engine with dependency of old jupiter 5.7.0. So I was interested what happens if we can still use it by override it to 5.8.0. I found that the `testng-junit5` still works. I excluded the dependency and did not override it directly for internal testing purposes and for the reason to avoid a situation that I override Jupiter API to 5.8.2 but Jupiter Engine 5.7.0. -- 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
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #500: [SUREFIRE-2024] Replace testng-junit5 by testng-engine
Tibor17 edited a comment on pull request #500: URL: https://github.com/apache/maven-surefire/pull/500#issuecomment-1081618294 In the old revision of `com.github.testng-team:testng-junit5`, the exclusion was because the TestNG team released only one version of the engine with dependency of old `junit-platform-engine` 1.7.0. So I was interested what happens if we can still use it by override it to 1.8.0. I found that the `testng-junit5` still works. I excluded the dependency and did not override it directly for internal testing purposes and for the reason to avoid a situation that I override Jupiter API to 5.8.2 but `junit-platform-engine` 1.7.0. -- 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
[GitHub] [maven-surefire] Tibor17 commented on pull request #500: [SUREFIRE-2024] Replace testng-junit5 by testng-engine
Tibor17 commented on pull request #500: URL: https://github.com/apache/maven-surefire/pull/500#issuecomment-1081634626 @slawekjaranowski > And next https://repo1.maven.org/maven2/org/junit/support/testng-engine/1.0.1/testng-engine-1.0.1.pom > has dependency to testng in runtime scope > but for junit-platform-engine they use compile scope. They would appear in our test classpath. See the table which describes that runtime and compile scope artifacts would be resolved in test classpath. https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope -- 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
[GitHub] [maven-mvnd] Oliverwqcwrw closed issue #613: [bug] The first exec mvnd clean install is failed every time
Oliverwqcwrw closed issue #613: URL: https://github.com/apache/maven-mvnd/issues/613 -- 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
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #500: [SUREFIRE-2024] Replace testng-junit5 by testng-engine
Tibor17 edited a comment on pull request #500: URL: https://github.com/apache/maven-surefire/pull/500#issuecomment-1081634626 @slawekjaranowski > And next https://repo1.maven.org/maven2/org/junit/support/testng-engine/1.0.1/testng-engine-1.0.1.pom > has dependency to testng in runtime scope > but for junit-platform-engine they use compile scope. They would appear in our test classpath. See the table which describes that runtime and compile scoped artifacts would be resolved in test classpath. https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope -- 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
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #500: [SUREFIRE-2024] Replace testng-junit5 by testng-engine
Tibor17 edited a comment on pull request #500: URL: https://github.com/apache/maven-surefire/pull/500#issuecomment-1081618294 In the old revision of `com.github.testng-team:testng-junit5`, the exclusion was because the TestNG team released only one version of the engine with dependency of old `junit-platform-engine` 1.7.0. So I was interested what happens if we can still use it by override it to 1.8.2. I found that the `testng-junit5` still works. I excluded the dependency and did not override it directly for internal testing purposes and for the reason to avoid a situation that I override Jupiter API to 5.8.2 but `junit-platform-engine` 1.7.0. -- 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
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #500: [SUREFIRE-2024] Replace testng-junit5 by testng-engine
slawekjaranowski commented on pull request #500: URL: https://github.com/apache/maven-surefire/pull/500#issuecomment-1081652953 Now with newer version of `testng-engine` is better I think. Simply can be used with the newest `junit-jupiter-api:5.8.2` and simple configuration should be shown to user. So I prefer to not propagate workaround with exclusion to users, whose simply copy and paste it. Is it exclusion is still needed and reasonable? If it is needed and we show it, we should describe why we use exclusion? I hope that JUnit team upgrade `testng-engine` to newest version of `junit-platform`. WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7444) Multiple optional non-existing projects not logged correctly
Maarten Mulders created MNG-7444:
Summary: Multiple optional non-existing projects not logged
correctly
Key: MNG-7444
URL: https://issues.apache.org/jira/browse/MNG-7444
Project: Maven
Issue Type: Bug
Components: Reactor and Workspace
Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
(31193cbf0c93205a63c8c7b372b09200f60e69f4)
Reporter: Maarten Mulders
Run {{mvn -pl \?:a,\?:b validate}} (escaping necessary on POSIX compliant
shells, Windows doesn't need it) on a project that does not have a module
{{:a}} and {{:b}}.
Expected:
{code}
[INFO] Could not find the selected project(s) in the reactor: :a, :b
{code}
Actual:
{code}
[INFO] Could not find the selected project in the reactor: :a
{code}
The output of {{mvn -help}} with regards to {{-pl}}:
{quote}Comma-delimited list of specified reactor projects to build instead of
all projects. A project can be specified by [groupId]:artifactId or by its
relative path. Prefixing a project with ! excludes it, and ? marks it as
optional{quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MSHARED-1050) ConcurrentModificationException for maven-filtering
Ladislav Lencucha created MSHARED-1050:
--
Summary: ConcurrentModificationException for maven-filtering
Key: MSHARED-1050
URL: https://issues.apache.org/jira/browse/MSHARED-1050
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Reporter: Ladislav Lencucha
Maven filtering is not thread safe. Adding all properties from request maven
session results in ConcurrentModificationException.
Problem is line 117 (and possibly also 118):
[https://github.com/apache/maven-filtering/blob/maven-filtering-3.1.1/src/main/java/org/apache/maven/shared/filtering/BaseFilter.java]
*How to simulate:*
# use maven-resources-plugin which relies on maven-filtering
## maven-resources-plugin version 3.1.0
## maven-filtering version 3.1.1
# have multithreaded build (e.g. mvn package -T 48)
# problem does not happen all the time, but more threads improve the chances
*JDK*
openjdk 11.0.11 2021-04-20
OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.18.04)
OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.18.04, mixed mode,
sharing)
*Possible cause:*
I have no clue, everything seems to be synchronized
*Sample stacktrace of failed build:*
{code:java}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources
(default-resources) on project sample-projct: Execution default-resources of
goal org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next (Hashtable.java:1387)
at java.util.Hashtable.putAll (Hashtable.java:523)
at org.apache.maven.shared.filtering.BaseFilter.getDefaultFilterWrappers
(BaseFilter.java:117)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFilterWrappers
(DefaultMavenFileFilter.java:53)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.handleDefaultFilterWrappers
(DefaultMavenResourcesFiltering.java:269)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:132)
at org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:345)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java
[jira] [Updated] (MSHARED-1050) ConcurrentModificationException for maven-filtering
[
https://issues.apache.org/jira/browse/MSHARED-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ladislav Lencucha updated MSHARED-1050:
---
Description:
Maven filtering is not thread safe. Adding all properties from request maven
session results in ConcurrentModificationException.
Problem is line 117 (and possibly also 118):
[https://github.com/apache/maven-filtering/blob/maven-filtering-3.1.1/src/main/java/org/apache/maven/shared/filtering/BaseFilter.java]
*How to simulate:*
# use maven-resources-plugin which relies on maven-filtering
## maven-resources-plugin version 3.1.0
## maven-filtering version 3.1.1
# have multithreaded build (e.g. mvn package -T 48)
# problem does not happen all the time, but more threads improve the chances
*JDK*
Oracle JDK 1.8
*Possible cause:*
I have no clue, everything seems to be synchronized
*Sample stacktrace of failed build:*
{code:java}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources
(default-resources) on project sample-projct: Execution default-resources of
goal org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next (Hashtable.java:1387)
at java.util.Hashtable.putAll (Hashtable.java:523)
at org.apache.maven.shared.filtering.BaseFilter.getDefaultFilterWrappers
(BaseFilter.java:117)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFilterWrappers
(DefaultMavenFileFilter.java:53)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.handleDefaultFilterWrappers
(DefaultMavenResourcesFiltering.java:269)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:132)
at org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:345)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multith
[jira] [Updated] (MSHARED-1050) ConcurrentModificationException for maven-filtering
[
https://issues.apache.org/jira/browse/MSHARED-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ladislav Lencucha updated MSHARED-1050:
---
Description:
Maven filtering is not thread safe. Adding all properties from request maven
session results in ConcurrentModificationException.
Problem is line 117 (and possibly also 118):
[https://github.com/apache/maven-filtering/blob/maven-filtering-3.1.1/src/main/java/org/apache/maven/shared/filtering/BaseFilter.java]
*How to simulate:*
# use maven-resources-plugin which relies on maven-filtering
## maven-resources-plugin version 3.1.0
## maven-filtering version 3.1.1
# have multithreaded build (e.g. mvn package -T 48)
# problem does not happen all the time, but more threads improve the chances
*JDK*
Oracle JDK 1.8
*Possible cause:*
I have no clue, everything seems to be synchronized. Maybe the collection is
being added to itself and that is why synchronized set wrapper did not work?
*Sample stacktrace of failed build:*
{code:java}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources
(default-resources) on project sample-projct: Execution default-resources of
goal org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:186)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)
Caused by: java.util.ConcurrentModificationException
at java.util.Hashtable$Enumerator.next (Hashtable.java:1387)
at java.util.Hashtable.putAll (Hashtable.java:523)
at org.apache.maven.shared.filtering.BaseFilter.getDefaultFilterWrappers
(BaseFilter.java:117)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.getDefaultFilterWrappers
(DefaultMavenFileFilter.java:53)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.handleDefaultFilterWrappers
(DefaultMavenResourcesFiltering.java:269)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:132)
at org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:345)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buil
[jira] [Closed] (SUREFIRE-1432) trimStackTrace = false by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1432.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=32f7dd36208abe059f6cfb01e79571b03c158806
> trimStackTrace = false by default
> -
>
> Key: SUREFIRE-1432
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1432
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *New description:*
> Currently, the default value of the config parameter _trimStackTrace_ is set
> to _true_. This fix changes the default value.
> *Old description:*
> Specify {{StackTraceInterpreterExtension}} abstract class with constructor
> parameter {{boolean trim}} and protected getter for {{trim}}. Single public
> method {{interpret(context): String}}.
> DefaultStackTraceImpl - current implementation that trimmed trace prints only
> test class
> SmartStackTraceImpl - full trace or the following if trimmed (for error):
> java.lang.NullPointerException: msg
> o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
> o.a.s.m.NestedStackTraceInTheSamePackage
> o.a.s.m.NestedStackTraceInTheSamePackage
> ...
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> (for failure - assertion failed - only this: )
> SomeAssertionError: msg
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> Here is brief package displayed or full Java package if totally different
> from package in test.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] laeubi commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
laeubi commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1081805771 > Seems like a straightforward fix. If I understand correctly, one or both of Exactly! -- 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
[GitHub] [maven] laeubi edited a comment on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
laeubi edited a comment on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1081805771 > If I understand correctly, one or both of Exactly! -- 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
[GitHub] [maven] michael-o commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
michael-o commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1081813900 Is there an IT for this? If there would be, I'd check this and add for 3.8.6+. -- 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
[GitHub] [maven-integration-testing] michael-o commented on a change in pull request #141: [MNG-7404] Drop support for prefixless expressions
michael-o commented on a change in pull request #141: URL: https://github.com/apache/maven-integration-testing/pull/141#discussion_r837423845 ## File path: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2339BadProjectInterpolationPre4Test.java ## @@ -0,0 +1,75 @@ +package org.apache.maven.it; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; + +/** + * This is a test set for https://issues.apache.org/jira/browse/MNG-2339";>MNG-2339. + * + * + */ +public class MavenITmng2339BadProjectInterpolationPre4Test Review comment: This class isn't registered with the suite, how should this run? -- 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] [Assigned] (MNG-7404) Change from deprecated WARNING to FAIL the build for usage of {X} placeholders rather than ${project.X}
[
https://issues.apache.org/jira/browse/MNG-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7404:
---
Assignee: Maarten Mulders
> Change from deprecated WARNING to FAIL the build for usage of {X}
> placeholders rather than ${project.X}
> ---
>
> Key: MNG-7404
> URL: https://issues.apache.org/jira/browse/MNG-7404
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-1
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1
> Fix For: 4.0.x-candidate
>
>
> Currently we produce a {{WARNING}} in case of using {{version}} or alike.
> I would suggest to change {{WARNING}} into a failing build in such use cases.
> {code}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for 'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
> [WARNING] The expression ${version} is deprecated. Please use
> ${project.version} instead.
> {code}
> WDYT?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7444) Multiple optional non-existing projects not logged correctly
[
https://issues.apache.org/jira/browse/MNG-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514039#comment-17514039
]
Maarten Mulders commented on MNG-7444:
--
Probably related: if my project has two modules, say {{mc}} and {{mt}}, and I
run {{mvn -pl \?:a,\?:mc,\?:mt}}, Maven only builds {{mc}}. That's not OK, it
should also build {{mt}}.
> Multiple optional non-existing projects not logged correctly
>
>
> Key: MNG-7444
> URL: https://issues.apache.org/jira/browse/MNG-7444
> Project: Maven
> Issue Type: Bug
> Components: Reactor and Workspace
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (31193cbf0c93205a63c8c7b372b09200f60e69f4)
>Reporter: Maarten Mulders
>Priority: Trivial
> Labels: up-for-grabs
>
> Run {{mvn -pl \?:a,\?:b validate}} (escaping necessary on POSIX compliant
> shells, Windows doesn't need it) on a project that does not have a module
> {{:a}} and {{:b}}.
> Expected:
> {code}
> [INFO] Could not find the selected project(s) in the reactor: :a, :b
> {code}
> Actual:
> {code}
> [INFO] Could not find the selected project in the reactor: :a
> {code}
> The output of {{mvn -help}} with regards to {{-pl}}:
> {quote}Comma-delimited list of specified reactor projects to build instead of
> all projects. A project can be specified by [groupId]:artifactId or by its
> relative path. Prefixing a project with ! excludes it, and ? marks it as
> optional{quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] laeubi commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
laeubi commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1081853247 > Is there an IT for this? If there would be, I'd check this and add for 3.8.6+. [The jira](https://issues.apache.org/jira/browse/MNG-7432) has a link [to a reproducer](https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation) maybe this could be integrated an in itest or give a hint how to create 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
[GitHub] [maven] jglick commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
jglick commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1081854700 For reference, the Jenkins build error was at https://github.com/apache/maven/blob/3599d3414f046de2324203b78ddcf9b5e4388aa0/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L302 -- 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
[GitHub] [maven-integration-testing] mthmulders commented on a change in pull request #141: [MNG-7404] Drop support for prefixless expressions
mthmulders commented on a change in pull request #141: URL: https://github.com/apache/maven-integration-testing/pull/141#discussion_r837481932 ## File path: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2339BadProjectInterpolationPre4Test.java ## @@ -0,0 +1,75 @@ +package org.apache.maven.it; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import org.apache.maven.it.util.ResourceExtractor; + +import java.io.File; + +/** + * This is a test set for https://issues.apache.org/jira/browse/MNG-2339";>MNG-2339. + * + * + */ +public class MavenITmng2339BadProjectInterpolationPre4Test Review comment: It would not. But adding it to the suite would, so I've pushed an additional commit just for that. Thanks for pointing that out. Double checked: running the IT's with Maven 3.8.5 runs both test classes for MNG-2339, running with Maven 4.0.0-alpha-1-SNAPSHOT runs only one and skips this newly added 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
[GitHub] [maven] Giovds opened a new pull request #701: [MNG-7443] Make logging consistent between optional profiles and projects
Giovds opened a new pull request #701: URL: https://github.com/apache/maven/pull/701 This PR introduces a new class `ProjectSelector` which contains logic around getting projects based on selectors. This logic was moved from the `DefaultGraphBuilder` in order to make it re-usable for `MavenDefault`. Since the `ProjectSelector` is not going to be used in many other cases, and it is relatively lightweight, it was left out of DI intentionally. The reason for moving this logic is to be able to make use of just the optional active and inactive selectors logic, without having to rebuild the graph again. It is quite a big PR for an extra info log statement however, in order to function the same as optional profiles it also has to change some of its behaviour around resolving optional projects. Which is described in [MNG-7444](https://issues.apache.org/jira/browse/MNG-7444). Which breaks on [this line](https://github.com/apache/maven/blob/e85ff889b333b82da20b988fbb42bdbfdb814545/maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java#L231). E.g. with this PR whenever the following command will work as expected `mvn compile -pl ?:non-existing,?:existing`. By reporting the `non-existing` could not be found and by only building the `existing` as it would normally. Also fixes [MNG-7444](https://issues.apache.org/jira/browse/MNG-7444) --- Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [MNG-7443](https://issues.apache.org/jira/browse/MNG-7443) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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] (SUREFIRE-2051) Propagate `ArtifactResolutionException` while resolving artifacts in `SurefireDependencyResolver`
Halil İbrahim Şener created SUREFIRE-2051:
-
Summary: Propagate `ArtifactResolutionException` while resolving
artifacts in `SurefireDependencyResolver`
Key: SUREFIRE-2051
URL: https://issues.apache.org/jira/browse/SUREFIRE-2051
Project: Maven Surefire
Issue Type: Improvement
Affects Versions: 3.0.0-M5
Environment: Apache Maven 3.8.5
(3599d3414f046de2324203b78ddcf9b5e4388aa0)
maven-surefire-plugin 3.0.0-M5
Reporter: Halil İbrahim Şener
We see {{NullPointerException}}s from time to time, similar to
https://issues.apache.org/jira/browse/SUREFIRE-1837 and
https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
(SurefireDependencyResolver.java:218)
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
(SurefireDependencyResolver.java:230)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
(AbstractSurefireMojo.java:3215)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1908)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
and when debug is enabled:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
(AbstractSurefireMojo.java:4121)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
(AbstractSurefireMojo.java:4102)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1913)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
we had already upgraded to Maven 3.8.5 and it was still happening.
After digging the Surefire code, I realized NPE is a red herring because
Surefire doesn't propagate the issue during artifact resolution, and then
later, it fails with NPE. In our case, the remote repository wasn't reliable,
e.g., it sometimes returns 500.
I think Surefire should propagate the actual artifact resolution issue instead.
Similar to Maven compiler plugin
https://github.com/apache/maven-compiler-plugin/blob/785089d48541899b5c0a4677942b0f66c2f71d39/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1838
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2051) Propagate `ArtifactResolutionException` while resolving artifacts in `SurefireDependencyResolver`
[
https://issues.apache.org/jira/browse/SUREFIRE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Halil İbrahim Şener updated SUREFIRE-2051:
--
Description:
We see {{NullPointerException}} s from time to time, similar to
https://issues.apache.org/jira/browse/SUREFIRE-1837 and
https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
(SurefireDependencyResolver.java:218)
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
(SurefireDependencyResolver.java:230)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
(AbstractSurefireMojo.java:3215)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1908)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
and when debug is enabled:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
(AbstractSurefireMojo.java:4121)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
(AbstractSurefireMojo.java:4102)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1913)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
we had already upgraded to Maven 3.8.5 and it was still happening.
After digging the Surefire code, I realized NPE is a red herring because
Surefire doesn't propagate the issue during artifact resolution, and then
later, it fails with NPE. In our case, the remote repository wasn't reliable,
e.g., it sometimes returns 500.
I think Surefire should propagate the actual artifact resolution issue instead.
Similar to Maven compiler plugin
https://github.com/apache/maven-compiler-plugin/blob/785089d48541899b5c0a4677942b0f66c2f71d39/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1838
was:
We see {{NullPointerException}}s from time to time, similar to
https://issues.apache.org/jira/browse/SUREFIRE-1837 and
https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
(SurefireDependencyResolver.java:218)
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
(SurefireDependencyResolver.java:230)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
(AbstractSurefireMojo.java:3215)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1908)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
and when debug is enabled:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
(AbstractSurefireMojo.java:4121)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
(AbstractSurefireMojo.java:4102)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1913)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
we had already upgraded to Maven 3.8.5 and it was still happening.
After digging the Surefire code, I realized NPE is a red herring because
Surefire doesn't propagate the issue during artifact resolution, and then
later, it fails with NPE. In our case, the remote repository wasn't reliable,
e.g., it sometimes returns 500.
I think Surefire should propagate the actual artifact resolution issue instead.
Similar to Maven compiler plugin
https://github.co
[GitHub] [maven-surefire] hisener opened a new pull request #504: [SUREFIRE-2051] Propagate exceptions while resolving artifacts in `SurefireDependencyResolver`
hisener opened a new pull request #504: URL: https://github.com/apache/maven-surefire/pull/504 Surefire doesn't propagate the exception during artifact resolution, and then later, it fails with a `NullPointerException` when it needs to access the artifact. (in `AbstractSurefireMojo.java#L4125` or `SurefireDependencyResolver.java#L203`). This makes harder to understand the underlying issue. This change uses `ResolutionErrorHandler` to propagate the actual issue. --- Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) -- 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-2051) Propagate `ArtifactResolutionException` while resolving artifacts in `SurefireDependencyResolver`
[
https://issues.apache.org/jira/browse/SUREFIRE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Halil İbrahim Şener updated SUREFIRE-2051:
--
Description:
We see {{NullPointerException}} s from time to time, similar to
https://issues.apache.org/jira/browse/SUREFIRE-1837 and
https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
(AbstractSurefireMojo.java:4121)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
(AbstractSurefireMojo.java:4102)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1913)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
and when debug is enabled:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
(SurefireDependencyResolver.java:218)
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
(SurefireDependencyResolver.java:230)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
(AbstractSurefireMojo.java:3215)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1908)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
we had already upgraded to Maven 3.8.5 and it was still happening.
After digging the Surefire code, I realized NPE is a red herring because
Surefire doesn't propagate the issue during artifact resolution, and then
later, it fails with NPE. In our case, the remote repository wasn't reliable,
e.g., it sometimes returns 500.
I think Surefire should propagate the actual artifact resolution issue instead.
Similar to Maven compiler plugin
https://github.com/apache/maven-compiler-plugin/blob/785089d48541899b5c0a4677942b0f66c2f71d39/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1838
was:
We see {{NullPointerException}} s from time to time, similar to
https://issues.apache.org/jira/browse/SUREFIRE-1837 and
https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
(SurefireDependencyResolver.java:218)
at
org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
(SurefireDependencyResolver.java:230)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
(AbstractSurefireMojo.java:3215)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1908)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
and when debug is enabled:
{code}
Caused by: java.lang.NullPointerException: Cannot invoke
"java.io.File.getAbsolutePath()" because the return value of
"org.apache.maven.artifact.Artifact.getFile()" is null
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
(AbstractSurefireMojo.java:4121)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
(AbstractSurefireMojo.java:4102)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
(AbstractSurefireMojo.java:1913)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
(AbstractSurefireMojo.java:1894)
{code}
Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
we had already upgraded to Maven 3.8.5 and it was still happening.
After digging the Surefire code, I realized NPE is a red herring because
Surefire doesn't propagate the issue during artifact resolution, and then
later, it fails with NPE. In our case, the remote repository wasn't reliable,
e.g., it sometimes returns 500.
I think Surefire should propagate the actual artifact resolution issue instead.
Similar to Maven compiler plugin
https://github.
[jira] [Commented] (SUREFIRE-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514134#comment-17514134
]
Christopher Tubbs commented on SUREFIRE-2035:
-
[~sjaranowski] I can provide the full output of
{{System.getProperty("java.class.path")}}, but it is quite large, and not very
useful to see all the repeated elements. I did a {{diff}} on them (after
replacing colons with newlines) and the only difference was the lack of the
main jar artifact in M5 that was present in M4, which led me to my description
above. Showing the full output from both is only going to show that same
conclusion in a more verbose way.
So instead, I will work on providing a minimal project to reproduce this issue,
and provide the output of that, to be less verbose.
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, tests still seem to work okay, though I can't figure out
> why. However, if I try to launch a process using Java's ProcessBuilder using
> the same class path from {{System.getProperty("java.class.path")}}, that
> process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2035) Main artifact jar not present on test class path for tests
[
https://issues.apache.org/jira/browse/SUREFIRE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Tubbs updated SUREFIRE-2035:
Description:
While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, I
noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
causes the main artifact jar to be missing from the class path in test cases. I
was able to verify that by printing out
{{System.getProperty("java.class.path")}} before and after switching to M5, and
confirmed that the jar was missing after switching.
For some reason, unit tests still seem to work okay, though I can't figure out
why. However, if I try to launch a process using Java's ProcessBuilder using
the same class path from {{System.getProperty("java.class.path")}}, that
process fails with ClassNotFoundException, failing to find classes that should
definitely be present on the class path from the main artifact.
was:
While trying to troubleshoot https://github.com/apache/accumulo/issues/2555, I
noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
causes the main artifact jar to be missing from the class path in test cases. I
was able to verify that by printing out
{{System.getProperty("java.class.path")}} before and after switching to M5, and
confirmed that the jar was missing after switching.
For some reason, tests still seem to work okay, though I can't figure out why.
However, if I try to launch a process using Java's ProcessBuilder using the
same class path from {{System.getProperty("java.class.path")}}, that process
fails with ClassNotFoundException, failing to find classes that should
definitely be present on the class path from the main artifact.
> Main artifact jar not present on test class path for tests
> --
>
> Key: SUREFIRE-2035
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2035
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Christopher Tubbs
>Priority: Critical
>
> While trying to troubleshoot https://github.com/apache/accumulo/issues/2555,
> I noticed that there was a behavior change between 3.0.0-M4 and 3.0.0-M5 that
> causes the main artifact jar to be missing from the class path in test cases.
> I was able to verify that by printing out
> {{System.getProperty("java.class.path")}} before and after switching to M5,
> and confirmed that the jar was missing after switching.
> For some reason, unit tests still seem to work okay, though I can't figure
> out why. However, if I try to launch a process using Java's ProcessBuilder
> using the same class path from {{System.getProperty("java.class.path")}},
> that process fails with ClassNotFoundException, failing to find classes that
> should definitely be present on the class path from the main artifact.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRELEASE-932) ReleaseFailureException of an artifact with version as a property
[
https://issues.apache.org/jira/browse/MRELEASE-932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514176#comment-17514176
]
Cesar Hernandez commented on MRELEASE-932:
--
This seems to be related to this issue too:
https://issues.apache.org/jira/browse/MRELEASE-913
https://issues.apache.org/jira/browse/MRELEASE-799
> ReleaseFailureException of an artifact with version as a property
> -
>
> Key: MRELEASE-932
> URL: https://issues.apache.org/jira/browse/MRELEASE-932
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.5.1, 2.5.3
> Environment: Maven 3.2.1
> Windows 7
> Intel Core i7
>Reporter: Antoine
>Priority: Major
> Labels: bug
> Attachments: MRELEASE-932.zip
>
>
> After updating the release maven plugin from version 2.0.0 to 2.5.1, I've got
> the following exception:
> {noformat}
> message : Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare (default-cli) on
> project ping-parent: The artifact (com.mycompagny.myapp:myapp-client)
> requires a different version (15.4.0) than what is found (12.2.1) for the
> expression (version.client.tested) in the project
> (com.mycompagny.myapp:myapp-client).
> cause : The artifact (com.mycompagny.myapp:myapp-client) requires a different
> version (15.4.0) than what is found (12.2.1) for the expression
> (version.client.tested) in the project (com.mycompagny.myapp:myapp-client).
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.5.1:prepare
> (default-cli) on project ping-parent: The artifact
> (fr.generali.gael.ping:ping-injection-client) requires a different version
> (15.4.1-git) than what is found (15.4.0) for the expression
> (version.client.tested) in the project
> (fr.generali.gael.ping:ping-client-test).
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java
> {noformat}
> This error happens in a multi-module application.
> For testing purpose, we depends from an older version of an artefact of the
> same application.
> When the artefact version is an expression (ie. $\{version.client.tested\}),
> the
> [AbstractRewritePomsPhase|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven.release/maven-release-manager/2.5.1/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java/#545]
> class do a chek.
> If we don't use the expression (i.e. properties), the release is working.
> Maven configuration that fails:
> {code}
>
> 12.1.0
>
>
> ${project.groupId}
> myapp-client
> ${version.client.tested}
>
> {code}
> Maven configuration that is working:
> {code}
>
> ${project.groupId}
> myapp-client
> 12.1.0
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MPMD-329) Upgrade to PMD 6.44.0
[ https://issues.apache.org/jira/browse/MPMD-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514206#comment-17514206 ] Andreas Dangel commented on MPMD-329: - Updated to PMD 6.44.0: https://gitbox.apache.org/repos/asf?p=maven-pmd-plugin.git;a=commit;h=7fcdd7cb9e2f743c22369bfba4c91cd2f4e26b98 > Upgrade to PMD 6.44.0 > - > > Key: MPMD-329 > URL: https://issues.apache.org/jira/browse/MPMD-329 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-pmd-plugin] adangel opened a new pull request #63: [MPMD-332] - Support Java 18
adangel opened a new pull request #63: URL: https://github.com/apache/maven-pmd-plugin/pull/63 Jira: https://issues.apache.org/jira/browse/MPMD-332 This PR adds an IT for Java 18 and updates the doc for parameter `targetJdk`. Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MPMD) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- 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] (MPMD-329) Upgrade to PMD 6.44.0
[ https://issues.apache.org/jira/browse/MPMD-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel resolved MPMD-329. - Resolution: Fixed > Upgrade to PMD 6.44.0 > - > > Key: MPMD-329 > URL: https://issues.apache.org/jira/browse/MPMD-329 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPMD-329) Upgrade to PMD 6.44.0
[ https://issues.apache.org/jira/browse/MPMD-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514251#comment-17514251 ] Hudson commented on MPMD-329: - Build failed in Jenkins: Maven » Maven TLP » maven-pmd-plugin » master #15 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-pmd-plugin/job/master/15/ > Upgrade to PMD 6.44.0 > - > > Key: MPMD-329 > URL: https://issues.apache.org/jira/browse/MPMD-329 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.17.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MARTIFACT-24) add goal to check that plugins versions do not have known reproducibility issues
[ https://issues.apache.org/jira/browse/MARTIFACT-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514286#comment-17514286 ] Herve Boutemy commented on MARTIFACT-24: perhaps we can use the same logic as buildplan-maven-plugin https://github.com/jcgay/buildplan-maven-plugin > add goal to check that plugins versions do not have known reproducibility > issues > > > Key: MARTIFACT-24 > URL: https://issues.apache.org/jira/browse/MARTIFACT-24 > Project: Maven Artifact Plugin > Issue Type: New Feature > Components: artifact:buildinfo, artifact:compare >Reporter: Herve Boutemy >Priority: Major > > for newbies wanting to make their build reproducible, having a first analysis > of what to fix in their pom.xml would ease a lot: we have a list of known > plugins with minimal versions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (SUREFIRE-2052) Handles internal exceptions do not have suppressed exceptions in ThreadedStreamConsumer
Tibor Digana created SUREFIRE-2052:
--
Summary: Handles internal exceptions do not have suppressed
exceptions in ThreadedStreamConsumer
Key: SUREFIRE-2052
URL: https://issues.apache.org/jira/browse/SUREFIRE-2052
Project: Maven Surefire
Issue Type: Improvement
Components: process forking
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 3.0.0-M6
If the internal exception is caught (e.g. casting Long to long throws NPE), we
do not see the stacktrace of the cause.
The stacktrace is:
{noformat}
# Created at 2022-03-29T01:16:09.607
ForkStarter IOException: java.lang.NullPointerException
java.lang.NullPointerException
java.lang.NullPointerException.
org.apache.maven.plugin.surefire.booterclient.output.MultipleFailureException:
java.lang.NullPointerException
java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.(ThreadedStreamConsumer.java:64)
at
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.(ThreadedStreamConsumer.java:122)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:600)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:311)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:268)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1327)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1160)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:925)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
{noformat}
This fix adds suppressed exception and removes repeative code.
The stacktrace would become:
{noformat}
# Created at 2022-03-29T22:27:27.705
ForkStarter IOException: java.lang.NullPointerException.
org.apache.maven.plugin.surefire.booterclient.output.MultipleFailureException:
java.lang.NullPointerException
at
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.(ThreadedStreamConsumer.java:64)
at
org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.(ThreadedStreamConsumer.java:122)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:600)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:311)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:268)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1327)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1160)
at
org.apache.maven.plugin.surefire.AbstractSurefi
[jira] [Closed] (SUREFIRE-2052) Handles internal exceptions do not have suppressed exceptions in ThreadedStreamConsumer
[
https://issues.apache.org/jira/browse/SUREFIRE-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2052.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=25425c379dd2a77001f17a71dce1eec04975a15e
> Handles internal exceptions do not have suppressed exceptions in
> ThreadedStreamConsumer
> ---
>
> Key: SUREFIRE-2052
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2052
> Project: Maven Surefire
> Issue Type: Improvement
> Components: process forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> If the internal exception is caught (e.g. casting Long to long throws NPE),
> we do not see the stacktrace of the cause.
> The stacktrace is:
> {noformat}
> # Created at 2022-03-29T01:16:09.607
> ForkStarter IOException: java.lang.NullPointerException
> java.lang.NullPointerException
> java.lang.NullPointerException.
> org.apache.maven.plugin.surefire.booterclient.output.MultipleFailureException:
> java.lang.NullPointerException
> java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.(ThreadedStreamConsumer.java:64)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.(ThreadedStreamConsumer.java:122)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:600)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:311)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:268)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1327)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1160)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:925)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {noformat}
> This fix adds suppressed exception and removes repeative code.
> The stacktrace would become:
> {noformat}
> # Created at 2022-03-29T22:27:27.705
> ForkStarter IOException: java.lang.NullPointerException.
> org.apache.maven.plugin.surefire.booterclient.output.MultipleFailureException:
> java.lang.NullPointerException
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.(ThreadedStreamConsumer.java:64)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.(ThreadedStreamConsumer.java:122)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:600)
> at
> org.apache.maven.plugin.
[jira] [Commented] (MSHADE-393) Upgrade project from Java 7 to 8
[ https://issues.apache.org/jira/browse/MSHADE-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514352#comment-17514352 ] Karl Heinz Marbaise commented on MSHADE-393: Done in [33273411d3033bc866bba46ec5f2fc39e60b|https://gitbox.apache.org/repos/asf?p=maven-shade-plugin.git;a=commitdiff;h=33273411d3033bc866bba46ec5f2fc39e60b] > Upgrade project from Java 7 to 8 > > > Key: MSHADE-393 > URL: https://issues.apache.org/jira/browse/MSHADE-393 > Project: Maven Shade Plugin > Issue Type: Task >Affects Versions: 3.2.4 >Reporter: Alexander Kriegisch >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.4.0 > > > If there is no specific reason forcing us to stay on Java source and target > level 7, I suggest upgrading to Java 8. When working on pull requests, it > felt quite uncomfortable not being able to use streams, interface default > methods, lambdas. > Is there a huge user base using Java 7 and still relying on Maven Shade > upgrades? I.e. they want the latest features and bugfixes, but are unable to > migrate to Java 8. That would be quite a sense of entitlement on their part. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MSHADE-393) Upgrade project from Java 7 to 8
[ https://issues.apache.org/jira/browse/MSHADE-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHADE-393. -- Resolution: Done > Upgrade project from Java 7 to 8 > > > Key: MSHADE-393 > URL: https://issues.apache.org/jira/browse/MSHADE-393 > Project: Maven Shade Plugin > Issue Type: Task >Affects Versions: 3.2.4 >Reporter: Alexander Kriegisch >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.4.0 > > > If there is no specific reason forcing us to stay on Java source and target > level 7, I suggest upgrading to Java 8. When working on pull requests, it > felt quite uncomfortable not being able to use streams, interface default > methods, lambdas. > Is there a huge user base using Java 7 and still relying on Maven Shade > upgrades? I.e. they want the latest features and bugfixes, but are unable to > migrate to Java 8. That would be quite a sense of entitlement on their part. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (MSHADE-404) Releasing 3.3.0
[ https://issues.apache.org/jira/browse/MSHADE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise resolved MSHADE-404. Resolution: Fixed > Releasing 3.3.0 > --- > > Key: MSHADE-404 > URL: https://issues.apache.org/jira/browse/MSHADE-404 > Project: Maven Shade Plugin > Issue Type: Task >Affects Versions: 3.3.0 >Reporter: Philipp Dallig >Priority: Major > > Hi, > it would be great if you could release 3.3.0, which includes the latest fixes > that are already part of the master branch. > The problem https://issues.apache.org/jira/browse/MSHADE-396 is solved in the > master branch and can be marked as solved in JIRA. > Best Regards > Philipp > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-404) Releasing 3.3.0
[ https://issues.apache.org/jira/browse/MSHADE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514357#comment-17514357 ] Karl Heinz Marbaise commented on MSHADE-404: Release announced: https://blogs.apache.org/maven/entry/apache-maven-shade-plugin-version6 > Releasing 3.3.0 > --- > > Key: MSHADE-404 > URL: https://issues.apache.org/jira/browse/MSHADE-404 > Project: Maven Shade Plugin > Issue Type: Task >Affects Versions: 3.3.0 >Reporter: Philipp Dallig >Priority: Major > > Hi, > it would be great if you could release 3.3.0, which includes the latest fixes > that are already part of the master branch. > The problem https://issues.apache.org/jira/browse/MSHADE-396 is solved in the > master branch and can be marked as solved in JIRA. > Best Regards > Philipp > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-397) The test for MSHADE-340 fails
[ https://issues.apache.org/jira/browse/MSHADE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514360#comment-17514360 ] Karl Heinz Marbaise commented on MSHADE-397: Based on the latest results all IT's are working fine. So I will close this issue. If you have further information please don't hesitate to reopen or create a new ticket. > The test for MSHADE-340 fails > - > > Key: MSHADE-397 > URL: https://issues.apache.org/jira/browse/MSHADE-397 > Project: Maven Shade Plugin > Issue Type: Bug >Reporter: Niels Basjes >Priority: Major > > When implementing the changes related to MSHADE-326 in Apache Maven itself > this test fails over the jar plugin. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MSHADE-397) The test for MSHADE-340 fails
[ https://issues.apache.org/jira/browse/MSHADE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHADE-397. -- Resolution: Cannot Reproduce > The test for MSHADE-340 fails > - > > Key: MSHADE-397 > URL: https://issues.apache.org/jira/browse/MSHADE-397 > Project: Maven Shade Plugin > Issue Type: Bug >Reporter: Niels Basjes >Priority: Major > > When implementing the changes related to MSHADE-326 in Apache Maven itself > this test fails over the jar plugin. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-413) Maven share plugin enters endless loop
[
https://issues.apache.org/jira/browse/MSHADE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514370#comment-17514370
]
Karl Heinz Marbaise commented on MSHADE-413:
* First I can't even compile the whole project as given with step 3, because a
dependency is missing: {{io.delta:delta-core_2.12:jar:1.1.0-nessie}} which does
not exist in central.
* Furthermore I can not reproduce the Step 4. because I can run it without any
issue...
> Maven share plugin enters endless loop
> ---
>
> Key: MSHADE-413
> URL: https://issues.apache.org/jira/browse/MSHADE-413
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Robert Stupp
>Priority: Critical
>
> Two issues at play here:
> * {{ShadeMojo.createDependencyReducedPom()}} pulls in {{origDeps =
> project.getDependencies()}} and later modifies these {{Dependency}} objects.
> * {{ShadeMojo.updateExcludesInDeps()}} enters it's own endless loop,
> endlessly adding the exact same exclusions.
> This leads to a
> [reproducible|https://github.com/projectnessie/nessie/issues/3678] endless
> loop (see below).
> If the Shade plugin's not using the {{Dependency}} objects "owned by Maven
> itself" (by setting {{promoteTransitiveDependencies}} to {{true}}), the build
> passes fine.
> I think, _modifying_ the {{Dependency}} objects "owned by Maven itself" is
> bad for two reasons (which IMO justify the increased priority of this
> ticket):
> # the reproducible endless loop
> # it breaks the correctness of the project build - at least plugins running
> after the {{shade}} goal that use those dependencies.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #504: [SUREFIRE-2051] Propagate exceptions while resolving artifacts in `SurefireDependencyResolver`
Tibor17 commented on pull request #504: URL: https://github.com/apache/maven-surefire/pull/504#issuecomment-1082479598 Right on the time! We are about to cut the release. Pls make requested updates. -- 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
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #504: [SUREFIRE-2051] Propagate exceptions while resolving artifacts in `SurefireDependencyResolver`
Tibor17 commented on a change in pull request #504: URL: https://github.com/apache/maven-surefire/pull/504#discussion_r838001570 ## File path: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireDependencyResolver.java ## @@ -184,7 +189,17 @@ private ArtifactResolutionResult resolveArtifact( Artifact artifact, List
[jira] [Commented] (MSHADE-415) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MSHADE-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514372#comment-17514372 ] Karl Heinz Marbaise commented on MSHADE-415: Done in [49e5aec4803491babb2dcab893c488c3f835937f|https://gitbox.apache.org/repos/asf?p=maven-shade-plugin.git;a=commitdiff;h=49e5aec4803491babb2dcab893c488c3f835937f] > Upgrade maven-plugin parent to 35 > - > > Key: MSHADE-415 > URL: https://issues.apache.org/jira/browse/MSHADE-415 > Project: Maven Shade Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.3.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MSHADE-415) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MSHADE-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MSHADE-415. -- Resolution: Done > Upgrade maven-plugin parent to 35 > - > > Key: MSHADE-415 > URL: https://issues.apache.org/jira/browse/MSHADE-415 > Project: Maven Shade Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.3.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2051) Propagate `ArtifactResolutionException` while resolving artifacts in `SurefireDependencyResolver`
[
https://issues.apache.org/jira/browse/SUREFIRE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2051:
---
Fix Version/s: 3.0.0-M6
> Propagate `ArtifactResolutionException` while resolving artifacts in
> `SurefireDependencyResolver`
> -
>
> Key: SUREFIRE-2051
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2051
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> maven-surefire-plugin 3.0.0-M5
>Reporter: Halil İbrahim Şener
>Priority: Minor
> Fix For: 3.0.0-M6
>
>
> We see {{NullPointerException}} s from time to time, similar to
> https://issues.apache.org/jira/browse/SUREFIRE-1837 and
> https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
> {code}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.File.getAbsolutePath()" because the return value of
> "org.apache.maven.artifact.Artifact.getFile()" is null
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
> (AbstractSurefireMojo.java:4121)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
> (AbstractSurefireMojo.java:4102)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1913)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1894)
> {code}
> and when debug is enabled:
> {code}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.File.getAbsolutePath()" because the return value of
> "org.apache.maven.artifact.Artifact.getFile()" is null
> at
> org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
> (SurefireDependencyResolver.java:218)
> at
> org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
> (SurefireDependencyResolver.java:230)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
> (AbstractSurefireMojo.java:3215)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1908)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1894)
> {code}
> Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
> we had already upgraded to Maven 3.8.5 and it was still happening.
> After digging the Surefire code, I realized NPE is a red herring because
> Surefire doesn't propagate the issue during artifact resolution, and then
> later, it fails with NPE. In our case, the remote repository wasn't reliable,
> e.g., it sometimes returns 500.
> I think Surefire should propagate the actual artifact resolution issue
> instead. Similar to Maven compiler plugin
> https://github.com/apache/maven-compiler-plugin/blob/785089d48541899b5c0a4677942b0f66c2f71d39/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1838
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2051) Propagate `ArtifactResolutionException` while resolving artifacts in `SurefireDependencyResolver`
[
https://issues.apache.org/jira/browse/SUREFIRE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2051:
---
Priority: Major (was: Minor)
> Propagate `ArtifactResolutionException` while resolving artifacts in
> `SurefireDependencyResolver`
> -
>
> Key: SUREFIRE-2051
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2051
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> maven-surefire-plugin 3.0.0-M5
>Reporter: Halil İbrahim Şener
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> We see {{NullPointerException}} s from time to time, similar to
> https://issues.apache.org/jira/browse/SUREFIRE-1837 and
> https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
> {code}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.File.getAbsolutePath()" because the return value of
> "org.apache.maven.artifact.Artifact.getFile()" is null
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
> (AbstractSurefireMojo.java:4121)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
> (AbstractSurefireMojo.java:4102)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1913)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1894)
> {code}
> and when debug is enabled:
> {code}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.File.getAbsolutePath()" because the return value of
> "org.apache.maven.artifact.Artifact.getFile()" is null
> at
> org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
> (SurefireDependencyResolver.java:218)
> at
> org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
> (SurefireDependencyResolver.java:230)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
> (AbstractSurefireMojo.java:3215)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1908)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1894)
> {code}
> Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
> we had already upgraded to Maven 3.8.5 and it was still happening.
> After digging the Surefire code, I realized NPE is a red herring because
> Surefire doesn't propagate the issue during artifact resolution, and then
> later, it fails with NPE. In our case, the remote repository wasn't reliable,
> e.g., it sometimes returns 500.
> I think Surefire should propagate the actual artifact resolution issue
> instead. Similar to Maven compiler plugin
> https://github.com/apache/maven-compiler-plugin/blob/785089d48541899b5c0a4677942b0f66c2f71d39/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1838
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-2051) Propagate `ArtifactResolutionException` while resolving artifacts in `SurefireDependencyResolver`
[
https://issues.apache.org/jira/browse/SUREFIRE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2051:
---
Component/s: Maven Failsafe Plugin
Maven Surefire Plugin
> Propagate `ArtifactResolutionException` while resolving artifacts in
> `SurefireDependencyResolver`
> -
>
> Key: SUREFIRE-2051
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2051
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> maven-surefire-plugin 3.0.0-M5
>Reporter: Halil İbrahim Şener
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> We see {{NullPointerException}} s from time to time, similar to
> https://issues.apache.org/jira/browse/SUREFIRE-1837 and
> https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
> {code}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.File.getAbsolutePath()" because the return value of
> "org.apache.maven.artifact.Artifact.getFile()" is null
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
> (AbstractSurefireMojo.java:4121)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
> (AbstractSurefireMojo.java:4102)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1913)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1894)
> {code}
> and when debug is enabled:
> {code}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.File.getAbsolutePath()" because the return value of
> "org.apache.maven.artifact.Artifact.getFile()" is null
> at
> org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
> (SurefireDependencyResolver.java:218)
> at
> org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
> (SurefireDependencyResolver.java:230)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
> (AbstractSurefireMojo.java:3215)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1908)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1894)
> {code}
> Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
> we had already upgraded to Maven 3.8.5 and it was still happening.
> After digging the Surefire code, I realized NPE is a red herring because
> Surefire doesn't propagate the issue during artifact resolution, and then
> later, it fails with NPE. In our case, the remote repository wasn't reliable,
> e.g., it sometimes returns 500.
> I think Surefire should propagate the actual artifact resolution issue
> instead. Similar to Maven compiler plugin
> https://github.com/apache/maven-compiler-plugin/blob/785089d48541899b5c0a4677942b0f66c2f71d39/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1838
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (SUREFIRE-2051) Propagate `ArtifactResolutionException` while resolving artifacts in `SurefireDependencyResolver`
[
https://issues.apache.org/jira/browse/SUREFIRE-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2051:
--
Assignee: Tibor Digana
> Propagate `ArtifactResolutionException` while resolving artifacts in
> `SurefireDependencyResolver`
> -
>
> Key: SUREFIRE-2051
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2051
> Project: Maven Surefire
> Issue Type: Improvement
>Affects Versions: 3.0.0-M5
> Environment: Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> maven-surefire-plugin 3.0.0-M5
>Reporter: Halil İbrahim Şener
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M6
>
>
> We see {{NullPointerException}} s from time to time, similar to
> https://issues.apache.org/jira/browse/SUREFIRE-1837 and
> https://issues.apache.org/jira/browse/SUREFIRE-1928. Relevant stack traces:
> {code}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.File.getAbsolutePath()" because the return value of
> "org.apache.maven.artifact.Artifact.getFile()" is null
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.setCachedClasspath
> (AbstractSurefireMojo.java:4121)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$ClasspathCache.access$200
> (AbstractSurefireMojo.java:4102)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1913)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1894)
> {code}
> and when debug is enabled:
> {code}
> Caused by: java.lang.NullPointerException: Cannot invoke
> "java.io.File.getAbsolutePath()" because the return value of
> "org.apache.maven.artifact.Artifact.getFile()" is null
> at
> org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspath
> (SurefireDependencyResolver.java:218)
> at
> org.apache.maven.plugin.surefire.SurefireDependencyResolver.getProviderClasspathAsMap
> (SurefireDependencyResolver.java:230)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo$JUnitPlatformProviderInfo.getProviderClasspath
> (AbstractSurefireMojo.java:3215)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.newStartupConfigWithClasspath
> (AbstractSurefireMojo.java:1908)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.createStartupConfiguration
> (AbstractSurefireMojo.java:1894)
> {code}
> Mentioned tickets point to https://github.com/apache/maven/pull/627. However,
> we had already upgraded to Maven 3.8.5 and it was still happening.
> After digging the Surefire code, I realized NPE is a red herring because
> Surefire doesn't propagate the issue during artifact resolution, and then
> later, it fails with NPE. In our case, the remote repository wasn't reliable,
> e.g., it sometimes returns 500.
> I think Surefire should propagate the actual artifact resolution issue
> instead. Similar to Maven compiler plugin
> https://github.com/apache/maven-compiler-plugin/blob/785089d48541899b5c0a4677942b0f66c2f71d39/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1838
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #504: [SUREFIRE-2051] Propagate exceptions while resolving artifacts in `SurefireDependencyResolver`
Tibor17 commented on a change in pull request #504: URL: https://github.com/apache/maven-surefire/pull/504#discussion_r838001570 ## File path: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireDependencyResolver.java ## @@ -184,7 +189,17 @@ private ArtifactResolutionResult resolveArtifact( Artifact artifact, List
[jira] [Commented] (MSHADE-393) Upgrade project from Java 7 to 8
[ https://issues.apache.org/jira/browse/MSHADE-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514418#comment-17514418 ] Hudson commented on MSHADE-393: --- Build succeeded in Jenkins: Maven » Maven TLP » maven-shade-plugin » master #13 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-shade-plugin/job/master/13/ > Upgrade project from Java 7 to 8 > > > Key: MSHADE-393 > URL: https://issues.apache.org/jira/browse/MSHADE-393 > Project: Maven Shade Plugin > Issue Type: Task >Affects Versions: 3.2.4 >Reporter: Alexander Kriegisch >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.4.0 > > > If there is no specific reason forcing us to stay on Java source and target > level 7, I suggest upgrading to Java 8. When working on pull requests, it > felt quite uncomfortable not being able to use streams, interface default > methods, lambdas. > Is there a huge user base using Java 7 and still relying on Maven Shade > upgrades? I.e. they want the latest features and bugfixes, but are unable to > migrate to Java 8. That would be quite a sense of entitlement on their part. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-415) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MSHADE-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514419#comment-17514419 ] Hudson commented on MSHADE-415: --- Build succeeded in Jenkins: Maven » Maven TLP » maven-shade-plugin » master #13 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-shade-plugin/job/master/13/ > Upgrade maven-plugin parent to 35 > - > > Key: MSHADE-415 > URL: https://issues.apache.org/jira/browse/MSHADE-415 > Project: Maven Shade Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.3.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-393) Upgrade project from Java 7 to 8
[ https://issues.apache.org/jira/browse/MSHADE-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514421#comment-17514421 ] Hudson commented on MSHADE-393: --- Build succeeded in Jenkins: Maven » Maven TLP » maven-shade-plugin » master #12 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-shade-plugin/job/master/12/ > Upgrade project from Java 7 to 8 > > > Key: MSHADE-393 > URL: https://issues.apache.org/jira/browse/MSHADE-393 > Project: Maven Shade Plugin > Issue Type: Task >Affects Versions: 3.2.4 >Reporter: Alexander Kriegisch >Assignee: Karl Heinz Marbaise >Priority: Major > Fix For: 3.4.0 > > > If there is no specific reason forcing us to stay on Java source and target > level 7, I suggest upgrading to Java 8. When working on pull requests, it > felt quite uncomfortable not being able to use streams, interface default > methods, lambdas. > Is there a huge user base using Java 7 and still relying on Maven Shade > upgrades? I.e. they want the latest features and bugfixes, but are unable to > migrate to Java 8. That would be quite a sense of entitlement on their part. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-415) Upgrade maven-plugin parent to 35
[ https://issues.apache.org/jira/browse/MSHADE-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514422#comment-17514422 ] Hudson commented on MSHADE-415: --- Build succeeded in Jenkins: Maven » Maven TLP » maven-shade-plugin » master #12 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-shade-plugin/job/master/12/ > Upgrade maven-plugin parent to 35 > - > > Key: MSHADE-415 > URL: https://issues.apache.org/jira/browse/MSHADE-415 > Project: Maven Shade Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.3.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.4.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
