[jira] [Commented] (SUREFIRE-1741) Exceptions in parameterized test sources are ignored

[Albert Johnston (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010189#comment-17010189
 ] 

Albert Johnston commented on SUREFIRE-1741:
---

Ok, I tried it with a local project, so there are other tests, but I added the 
following test:

 
{code:java}
static Stream argsThrow() {
  if (true) throw new RuntimeException();
  return Stream.of(
  Arguments.arguments()
  );
}

@ParameterizedTest
@MethodSource("argsThrow")
void testItThrow() {
  fail();
}
{code}
I targeted 3.0.0-SNAPSHOT, and when I tried it I got the same result as before.

 

 
{noformat}
[INFO] < omitted:omitted >-
[INFO] Building omitted 1.0-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ omitted 
---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 10 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ omitted ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
omitted ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 15 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ 
omitted ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 18 source files to D:\development\omitted\target\test-classes
[INFO]
[INFO] --- maven-surefire-plugin:3.0.0-SNAPSHOT:test (default-test) @ omitted 
---
[INFO]
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running omitted.OmittedTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.24 s - 
in omitted.OmittedTest
[INFO] Running omitted.OmittedOtherTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 s 
- in omitted.OmittedOtherTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  4.106 s
[INFO] Finished at: 2020-01-07T16:07:17-08:00
[INFO] 
{noformat}
So it doesn't seem to have fixed this issue. I can create a public repo to 
demonstrate this if necessary.

 

> Exceptions in parameterized test sources are ignored
> 
>
> Key: SUREFIRE-1741
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1741
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support, Maven Failsafe Plugin, Maven Surefire 
> Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
>  * JUnit Jupiter 5.5.1
>  * JDK 11.0.5
>  * Maven 3.6.1
>  
> If the following code is run, either for Surefire or Failsafe, only two of 
> the test methods are logged as having been detected at all. The third one is 
> completely ignored as if it didn't exist.
> {code:java}
> public class ExampleTest {
>   @Test
>   public void shouldRunAndPassAsExpected() {
>   }
>   public static Stream nothing() {
> return Stream.of(Arguments.arguments());
>   }
>   @ParameterizedTest
>   @MethodSource("nothing")
>   public void shouldRunAndFailAsExpected() {
> Assertions.fail();
>   }
>   static Stream throwException() {
> if (true) throw new RuntimeException("Stop");
> return Stream.of(Arguments.arguments());
>   }
>   @ParameterizedTest
>   @MethodSource("throwException")
>   void willNotBeLoggedAsFailingDespiteNotRunning() {
> Assertions.fail();
>   }
> }
> {code}
> This is particularly obvious if the first two test methods are commented out, 
> as running mvn test will log that 0 tests were run.
>  
> In case it helps, here's the output I'm seeing when running it with the first 
> two tests commented out:
> {noformat}
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running ExampleIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 s 
> - in ExampleIT
> [INFO] 
> [INFO] Results:
> [INFO] 
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1741) Exceptions in parameterized test sources are ignored

[Tibor Digana (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010158#comment-17010158
 ] 

Tibor Digana commented on SUREFIRE-1741:


[~ajohnston]
I have noticed that we made a fix in SUREFIRE-1688. Now it looks to me that the 
version {{3.0.0-SNAPSHOT}} may report failing test. Pls check it out with that 
and let us know how the test report looks like.

> Exceptions in parameterized test sources are ignored
> 
>
> Key: SUREFIRE-1741
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1741
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support, Maven Failsafe Plugin, Maven Surefire 
> Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
>  * JUnit Jupiter 5.5.1
>  * JDK 11.0.5
>  * Maven 3.6.1
>  
> If the following code is run, either for Surefire or Failsafe, only two of 
> the test methods are logged as having been detected at all. The third one is 
> completely ignored as if it didn't exist.
> {code:java}
> public class ExampleTest {
>   @Test
>   public void shouldRunAndPassAsExpected() {
>   }
>   public static Stream nothing() {
> return Stream.of(Arguments.arguments());
>   }
>   @ParameterizedTest
>   @MethodSource("nothing")
>   public void shouldRunAndFailAsExpected() {
> Assertions.fail();
>   }
>   static Stream throwException() {
> if (true) throw new RuntimeException("Stop");
> return Stream.of(Arguments.arguments());
>   }
>   @ParameterizedTest
>   @MethodSource("throwException")
>   void willNotBeLoggedAsFailingDespiteNotRunning() {
> Assertions.fail();
>   }
> }
> {code}
> This is particularly obvious if the first two test methods are commented out, 
> as running mvn test will log that 0 tests were run.
>  
> In case it helps, here's the output I'm seeing when running it with the first 
> two tests commented out:
> {noformat}
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running ExampleIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 s 
> - in ExampleIT
> [INFO] 
> [INFO] Results:
> [INFO] 
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] belingueres commented on a change in pull request #285: [MNG-5222] - Maven 3 no longer logs warnings about deprecated plugin

[GitBox]

belingueres commented on a change in pull request #285: [MNG-5222] - Maven 3 no 
longer logs warnings about deprecated plugin
URL: https://github.com/apache/maven/pull/285#discussion_r363995025
 
 

 ##
 File path: 
maven-core/src/main/java/org/apache/maven/plugin/internal/ValidatingConfigurationListener.java
 ##
 @@ -94,4 +110,57 @@ private void notify( String fieldName, Object value )
 }
 }
 
+private void warnDeprecated( String fieldName, Object value )
+{
+Parameter parameter = mojoDescriptor.getParameterMap().get( fieldName 
);
+String deprecated = parameter.getDeprecated();
+if ( deprecated != null && !deprecated.isEmpty() )
+{
+if ( !toString( value ).equals( toString( 
parameter.getDefaultValue() ) ) )
+{
+StringBuilder sb = new StringBuilder( "  Parameter '" );
+sb.append( fieldName ).append( '\'' );
+if ( parameter.getExpression() != null )
+{
+String userParam = parameter.getExpression().replace( 
"${", "'" ).replace( '}', '\'' );
+sb.append( " (User Parameter " ).append( userParam 
).append( ")" );
 
 Review comment:
   Do you have and example of such an old plugin? How do I know if it is a 
"valid expression" at this stage of the plugin execution?


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1741) Exceptions in parameterized test sources are ignored

[Albert Johnston (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010139#comment-17010139
 ] 

Albert Johnston commented on SUREFIRE-1741:
---

Alright, JUnit4 did seem to handle this differently. Here's the repo. 
[https://github.com/ajohnstonTE/JUnit4Test]

 

When running the "bundled" version I provide in that repo, this is the result:

 
{noformat}
> java -cp .;junit-4.12.jar;hamcrest-core-1.3.jar org.junit.runner.JUnitCore 
> TestClass
JUnit version 4.12
.E.E.
Time: 0.003
There were 2 failures:
1) 
initializationError(TestClass$WillNotBeLoggedAsFailingDespiteNotRunningWithParametersTest)
java.lang.RuntimeException
at 
TestClass$WillNotBeLoggedAsFailingDespiteNotRunningWithParametersTest.throwException(TestClass.java:37)
...(omitted)
2) test[0](TestClass$ShouldRunAndFailAsExpectedWithParametersTest)
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.fail(Assert.java:95)
at 
TestClass$ShouldRunAndFailAsExpectedWithParametersTest.test(TestClass.java:29)
...(omitted)

FAILURES!!!
Tests run: 3,  Failures: 2{noformat}
Note: I used the "Enclosed" class to bundle them into a single class/run 
command. But I also tried each test separately (also included in the repo), and 
the one with the exception in the parameters method still fails. Just so that 
there's at least a demonstration that truly only includes the stuff that needed 
to be tested.

> Exceptions in parameterized test sources are ignored
> 
>
> Key: SUREFIRE-1741
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1741
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support, Maven Failsafe Plugin, Maven Surefire 
> Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
>  * JUnit Jupiter 5.5.1
>  * JDK 11.0.5
>  * Maven 3.6.1
>  
> If the following code is run, either for Surefire or Failsafe, only two of 
> the test methods are logged as having been detected at all. The third one is 
> completely ignored as if it didn't exist.
> {code:java}
> public class ExampleTest {
>   @Test
>   public void shouldRunAndPassAsExpected() {
>   }
>   public static Stream nothing() {
> return Stream.of(Arguments.arguments());
>   }
>   @ParameterizedTest
>   @MethodSource("nothing")
>   public void shouldRunAndFailAsExpected() {
> Assertions.fail();
>   }
>   static Stream throwException() {
> if (true) throw new RuntimeException("Stop");
> return Stream.of(Arguments.arguments());
>   }
>   @ParameterizedTest
>   @MethodSource("throwException")
>   void willNotBeLoggedAsFailingDespiteNotRunning() {
> Assertions.fail();
>   }
> }
> {code}
> This is particularly obvious if the first two test methods are commented out, 
> as running mvn test will log that 0 tests were run.
>  
> In case it helps, here's the output I'm seeing when running it with the first 
> two tests commented out:
> {noformat}
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running ExampleIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 s 
> - in ExampleIT
> [INFO] 
> [INFO] Results:
> [INFO] 
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure

[Tibor Digana (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010135#comment-17010135
 ] 

Tibor Digana commented on SUREFIRE-1719:


[~paulmillar]
I am glad that it works for you. Pls use the version for some time because 
important changes have to be made in January and then we will cut a new release 
version.

> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3, 
> unit tests started to fail with the message "ExecutionException The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl 
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{  org.apache.maven.plugins}}
> {{  maven-surefire-plugin}}
> {{  }}
> {{    }}
> {{  **/*Test.class}}
> {{  **/*Tests.class}}
> {{    }}
> {{    }}
> {{    1C}}
> {{    false}}
> {{  }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the 
> problem appear 6 out of 10 times when running the above mvn command. There is 
> (apparently) little that seems to influence whether the build will succeed or 
> fail.
> [I've attached the complete output from running the above mvn command, both 
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores. 
> Our build machine has 24 cores, and I've seen a report of a similar problem 
> where building dCache on a 48 core machine. On the other side, I have been 
> unable to reproduce the problem with my desktop machine (8 core) or on my 
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on 
> a machine with a small number of cores. However, I've noticed that, on an 8 
> core machine, increasing the forkCount does not actually result in that many 
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM 
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood 
> of a problem below 10% (0 failures with 10 builds) on our build machine.  On 
> this machine, the default configuration would try to run 24 JVM instances 
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building 
> with surefire v2.19.1, the above mvn command is always successful on our 
> build machine.  Building with surefire v2.20 results in intermittent failures 
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10 
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342 
> Acknowledge normal exit of JVM and drain shared memory between processes" is 
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it 
> introduces is somehow racy (for example, reading or updating a field-member 
> outside of a monitor) and problems are triggered if there are a large number 
> of JVMs exiting concurrently.  So, with increased number of concurrent JVMs 
> there is an increased risk of a thread loosing the race, and so triggering 
> this error.
> Such a problem would be consistent with observed behaviour.  However, I don't 
> have any strong evidence that this is what is happening.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-release] rfscholte commented on issue #19: Fix for MRELEASE-835: Automatically resolve snapshot dependencies in release:prepare

[GitBox]

rfscholte commented on issue #19: Fix for MRELEASE-835: Automatically resolve 
snapshot dependencies in release:prepare
URL: https://github.com/apache/maven-release/pull/19#issuecomment-571794571
 
 
   much better :) let's see 
https://builds.apache.org/job/maven-box/job/maven-release/job/MRELEASE-835/


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-release] theit commented on issue #19: Fix for MRELEASE-835: Automatically resolve snapshot dependencies in release:prepare

[GitBox]

theit commented on issue #19: Fix for MRELEASE-835: Automatically resolve 
snapshot dependencies in release:prepare
URL: https://github.com/apache/maven-release/pull/19#issuecomment-571787762
 
 
   @rfscholte: Sorry for the noise, I used the wrong push command (typical user 
error)... :-/
   Can you try again please?
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (MDEP-665) Recognize "starters" during analyze

[Robert Scholte (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MDEP-665:

Description: 
Springboot introduces the concept of starters, which are a predefined set of 
dependencies. 
It is an empty jar, which acts as just a container for multiple dependencies. 
(it should have been a pom, but that means people suddenly need to add 
{{pom to their dependency)
Due to its popularity we should solve this during analyze: a starter should be 
a delegate for its dependencies. (in the code I would use the word 
{{delegate}}, not starter as it is too Spring specific)

  was:
Springboot introduces the concept of starters, which are a predefined set of 
dependencies. 
It is an empty jar, which acts as just a container for multiple dependencies. 
(it should have been a pom, but that means people suddenly need to add 
{{pom to their dependency)
Due to its popularity we should solve this during analyze: a starter should be 
a delegate for its dependencies.


> Recognize "starters" during analyze
> ---
>
> Key: MDEP-665
> URL: https://issues.apache.org/jira/browse/MDEP-665
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>  Components: analyze
>Reporter: Robert Scholte
>Priority: Major
>
> Springboot introduces the concept of starters, which are a predefined set of 
> dependencies. 
> It is an empty jar, which acts as just a container for multiple dependencies. 
> (it should have been a pom, but that means people suddenly need to add 
> {{pom to their dependency)
> Due to its popularity we should solve this during analyze: a starter should 
> be a delegate for its dependencies. (in the code I would use the word 
> {{delegate}}, not starter as it is too Spring specific)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MRELEASE-1036) fix javadoc for JDK 8

[Robert Scholte (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRELEASE-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte updated MRELEASE-1036:
-
Description: 
When running {{mvn verify site -Preporting}} the project fails due to javadoc 
errors. 
You might also see stacktraces caused by 
org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find 
org.eclipse.m2e:lifecycle-mapping:pom:1.0.0
These can be ignored and will be fixed with MPIR-375 once released.

> fix javadoc for JDK 8
> -
>
> Key: MRELEASE-1036
> URL: https://issues.apache.org/jira/browse/MRELEASE-1036
> Project: Maven Release Plugin
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 3.0.0-M1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.0.0
>
>
> When running {{mvn verify site -Preporting}} the project fails due to javadoc 
> errors. 
> You might also see stacktraces caused by 
> org.eclipse.aether.transfer.ArtifactNotFoundException: Failure to find 
> org.eclipse.m2e:lifecycle-mapping:pom:1.0.0
> These can be ignored and will be fixed with MPIR-375 once released.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-compiler-plugin] rfscholte commented on a change in pull request #27: MCOMPILER-372 - fix test compile issue: added dependency test path for modules

[GitBox]

rfscholte commented on a change in pull request #27: MCOMPILER-372 - fix test 
compile issue: added dependency test path for modules
URL: 
https://github.com/apache/maven-compiler-plugin/pull/27#discussion_r363877268
 
 

 ##
 File path: src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java
 ##
 @@ -380,28 +384,300 @@ else if ( Double.valueOf( getTarget() ) < 
Double.valueOf( MODULE_INFO_TARGET ) )
 {
 compilerArgs = new ArrayList<>();
 }
-compilerArgs.add( "--patch-module" );
+
+// Patch module to add 
+LinkedHashMap> patchModules = new 
LinkedHashMap<>();
+
+List mainModulePaths = new ArrayList<>();
+// Add main output dir
+mainModulePaths.add( mainOutputDirectory.getAbsolutePath() );
+// Add source roots
+mainModulePaths.addAll( compileSourceRoots );
+patchModules.put( mainModuleDescriptor.name(), mainModulePaths 
);
 
-StringBuilder patchModuleValue = new StringBuilder( 
mainModuleDescriptor.name() )
-.append( '=' )
-.append( mainOutputDirectory )
-.append( PS );
-for ( String root : compileSourceRoots )
+// Main module detected, modularized test dependencies must 
augment patch modules
+patchModulesForTestDependencies( 
+mainModuleDescriptor.name(), 
mainOutputDirectory.getAbsolutePath(),
+patchModules 
+);
+
+for ( Entry> patchModuleEntry: 
patchModules.entrySet() ) 
 {
-patchModuleValue.append( root ).append( PS );
+compilerArgs.add( "--patch-module" );
+StringBuilder patchModuleValue = new StringBuilder( 
patchModuleEntry.getKey() )
+.append( '=' );
+
+for ( String path : patchModuleEntry.getValue() )
+{
+patchModuleValue.append( path ).append( PS );
+}
+
+compilerArgs.add( patchModuleValue.toString() );
 }
 
-compilerArgs.add( patchModuleValue.toString() );
-
 compilerArgs.add( "--add-reads" );
 compilerArgs.add( mainModuleDescriptor.name() + "=ALL-UNNAMED" 
);
+
 }
 else
 {
 modulepathElements = Collections.emptyList();
 classpathElements = testPath;
 }
+
+}
+}
+
+/**
+ * Compiling with test classpath is not sufficient because some 
dependencies 
+ * may be modularized and their test class path addition would be 
ignored.
+ * Example from MCOMPILER-372_modularized_test:
+ * prj2 test classes depend on prj1 classes and test classes
+ * As prj1.jar is added as a module, pjr1-tests.jar classes are ignored if 
we add jar class path
+ * We have to add pjr1-tests.jar as --patch-module
+ * @param mainModuleName
+ * param mainModuleTarget
+ * @param patchModules map of module names - list of paths to add to 
--patch-module option
+ * 
+ */
+protected void patchModulesForTestDependencies( 
+String mainModuleName, String mainModuleTarget,
+LinkedHashMap> patchModules 
+)
+{
+ 
+File mainModuleDescriptorClassFile = new File( mainModuleTarget, 
"module-info.class" );
+
+ResolvePathsResult result;
+
+try
+{
+// Get compile path information to identify modularized compile 
path elements
+Collection dependencyArtifacts = 
getCompileClasspathElements( getProject() );
+
+ResolvePathsRequest request =
+ResolvePathsRequest.ofFiles( dependencyArtifacts )
+.setMainModuleDescriptor( mainModuleDescriptorClassFile );
+
+Toolchain toolchain = getToolchain();
+if ( toolchain instanceof DefaultJavaToolChain )
+{
+request.setJdkHome( new File( ( (DefaultJavaToolChain) 
toolchain ).getJavaHome() ) );
+}
+
+result = locationManager.resolvePaths( request );
+}
+catch ( IOException e )
+{
+throw new RuntimeException( e );
+}
+
+// Prepare a path list containing test paths for modularized paths
+// This path list will augment modules to be able to compile
+List listModuleTestPaths = new ArrayList<>( testPath.size() );
+
+// Browse modules
+for ( Entry pathElt : 
result.getModulepathElements().entrySet() )
+{
+
+

[GitHub] [maven-release] rfscholte commented on issue #19: Fix for MRELEASE-835: Automatically resolve snapshot dependencies in release:prepare

[GitBox]

rfscholte commented on issue #19: Fix for MRELEASE-835: Automatically resolve 
snapshot dependencies in release:prepare
URL: https://github.com/apache/maven-release/pull/19#issuecomment-571701170
 
 
   Still not possible. Can you try these instructions: 
https://github.com/wprig/wprig/wiki/How-to-squash-commits


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-release] theit commented on issue #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations

[GitBox]

theit commented on issue #32: [MRELEASE-549] Add support for the 
"--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#issuecomment-571621112
 
 
   Great, thanks!


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven] KroArtem commented on a change in pull request #312: [MNG-6844] replace string-defined charsets by StandardCharsets and remove unneeded suppressions

[GitBox]

KroArtem commented on a change in pull request #312: [MNG-6844] replace 
string-defined charsets by StandardCharsets and remove unneeded suppressions
URL: https://github.com/apache/maven/pull/312#discussion_r363743171
 
 

 ##
 File path: 
maven-compat/src/test/java/org/apache/maven/repository/legacy/StringWagon.java
 ##
 @@ -72,14 +73,7 @@ public void fillInputData( InputData inputData )
 resource.setContentLength( content.length() );
 resource.setLastModified( System.currentTimeMillis() );
 
-try
-{
-inputData.setInputStream( new ByteArrayInputStream( 
content.getBytes( "UTF-8" ) ) );
-}
-catch ( UnsupportedEncodingException e )
-{
-throw new Error( "broken JVM", e );
-}
+inputData.setInputStream( new ByteArrayInputStream( 
content.getBytes(StandardCharsets.UTF_8) ) );
 
 Review comment:
   That's strange, I've fixed it after running `clean verify`
   
   Will fix a bit later


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MNG-6806) Provide Maven BOM

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009683#comment-17009683
 ] 

Michael Osipov commented on MNG-6806:
-

[~cchacin], that's not possible. Assignees are only Maven committers. You can 
provide a PR, we will review and merge.

> Provide Maven BOM
> -
>
> Key: MNG-6806
> URL: https://issues.apache.org/jira/browse/MNG-6806
> Project: Maven
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.7.0-candidate
>
>
> Maven libraries should always have the same version to ensure they work as 
> expected, hence the preferred way to manage that is with a bom.
> Let's introduce the maven-bom.
> See https://www.baeldung.com/spring-maven-bom about how to write and use the 
> bom.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-release] theit commented on issue #19: Fix for MRELEASE-835: Automatically resolve snapshot dependencies in release:prepare

[GitBox]

theit commented on issue #19: Fix for MRELEASE-835: Automatically resolve 
snapshot dependencies in release:prepare
URL: https://github.com/apache/maven-release/pull/19#issuecomment-571562092
 
 
   @rfscholte: I've tried again to squash them and rebase the master branch 
into the PR. Can you again have a look please?


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-release] michael-o edited a comment on issue #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations

[GitBox]

michael-o edited a comment on issue #32: [MRELEASE-549] Add support for the 
"--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#issuecomment-571557231
 
 
   Scheduling for the end of the week.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven] michael-o commented on a change in pull request #312: [MNG-6844] replace string-defined charsets by StandardCharsets and remove unneeded suppressions

[GitBox]

michael-o commented on a change in pull request #312: [MNG-6844] replace 
string-defined charsets by StandardCharsets and remove unneeded suppressions
URL: https://github.com/apache/maven/pull/312#discussion_r363715018
 
 

 ##
 File path: 
maven-compat/src/test/java/org/apache/maven/repository/legacy/StringWagon.java
 ##
 @@ -72,14 +73,7 @@ public void fillInputData( InputData inputData )
 resource.setContentLength( content.length() );
 resource.setLastModified( System.currentTimeMillis() );
 
-try
-{
-inputData.setInputStream( new ByteArrayInputStream( 
content.getBytes( "UTF-8" ) ) );
-}
-catch ( UnsupportedEncodingException e )
-{
-throw new Error( "broken JVM", e );
-}
+inputData.setInputStream( new ByteArrayInputStream( 
content.getBytes(StandardCharsets.UTF_8) ) );
 
 Review comment:
   Formatting


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven] michael-o commented on a change in pull request #312: [MNG-6844] replace string-defined charsets by StandardCharsets and remove unneeded suppressions

[GitBox]

michael-o commented on a change in pull request #312: [MNG-6844] replace 
string-defined charsets by StandardCharsets and remove unneeded suppressions
URL: https://github.com/apache/maven/pull/312#discussion_r363715080
 
 

 ##
 File path: 
maven-core/src/test/java/org/apache/maven/project/ExtensionDescriptorBuilderTest.java
 ##
 @@ -61,14 +62,7 @@ protected void tearDown()
 
 private InputStream toStream( String xml )
 {
-try
-{
-return new ByteArrayInputStream( xml.getBytes( "UTF-8" ) );
-}
-catch ( UnsupportedEncodingException e )
-{
-throw new IllegalStateException( e );
-}
+return new ByteArrayInputStream( xml.getBytes(StandardCharsets.UTF_8) 
);
 
 Review comment:
   Formatting


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-release] michael-o commented on issue #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations

[GitBox]

michael-o commented on issue #32: [MRELEASE-549] Add support for the 
"--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#issuecomment-571557231
 
 
   Schedulung for the end of the week.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1741) Exceptions in parameterized test sources are ignored

[Tibor Digana (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009650#comment-17009650
 ] 

Tibor Digana commented on SUREFIRE-1741:


[~ajohnston]
I would like to see a comparison of the surefire test result with *JUnit4* 
parameterized test.
I hope it has something like this:
{{Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.02 s - in 
ExampleIT}}
Then we should reach the same outcome.
The code which determines this result is controlled by 
{{RunListenerAdapter#executionFinished()}} in surefire.

> Exceptions in parameterized test sources are ignored
> 
>
> Key: SUREFIRE-1741
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1741
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support, Maven Failsafe Plugin, Maven Surefire 
> Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Albert Johnston
>Priority: Major
>
> Associated versions on my end at time of testing:
>  * JUnit Jupiter 5.5.1
>  * JDK 11.0.5
>  * Maven 3.6.1
>  
> If the following code is run, either for Surefire or Failsafe, only two of 
> the test methods are logged as having been detected at all. The third one is 
> completely ignored as if it didn't exist.
> {code:java}
> public class ExampleTest {
>   @Test
>   public void shouldRunAndPassAsExpected() {
>   }
>   public static Stream nothing() {
> return Stream.of(Arguments.arguments());
>   }
>   @ParameterizedTest
>   @MethodSource("nothing")
>   public void shouldRunAndFailAsExpected() {
> Assertions.fail();
>   }
>   static Stream throwException() {
> if (true) throw new RuntimeException("Stop");
> return Stream.of(Arguments.arguments());
>   }
>   @ParameterizedTest
>   @MethodSource("throwException")
>   void willNotBeLoggedAsFailingDespiteNotRunning() {
> Assertions.fail();
>   }
> }
> {code}
> This is particularly obvious if the first two test methods are commented out, 
> as running mvn test will log that 0 tests were run.
>  
> In case it helps, here's the output I'm seeing when running it with the first 
> two tests commented out:
> {noformat}
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running ExampleIT
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 s 
> - in ExampleIT
> [INFO] 
> [INFO] Results:
> [INFO] 
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0{noformat}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] KroArtem opened a new pull request #312: [MNG-6844] replace string-defined charsets by StandardCharsets and remove unneeded suppressions

[GitBox]

KroArtem opened a new pull request #312: [MNG-6844] replace string-defined 
charsets by StandardCharsets and remove unneeded suppressions
URL: https://github.com/apache/maven/pull/312
 
 
   Following this checklist to help us incorporate your 
   contribution quickly and easily:
   
- [ ] Make sure there is a [JIRA 
issue](https://issues.apache.org/jira/browse/MNG) 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.
- [ ] Each commit in the pull request should have a meaningful subject line 
and body.
- [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in 
ApproximateQuantiles`,
  where you replace `MNG-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.
- [ ] 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)
   
- [ ] 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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-release] theit commented on issue #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations

[GitBox]

theit commented on issue #32: [MRELEASE-549] Add support for the 
"--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#issuecomment-571530928
 
 
   @michael-o: Did you already have a chance to look at this PR?


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (MNG-6844) Use StandardCharsets and remove outdated @SuppressWarnings

[Krosheninnikov Artem (Jira)]

Krosheninnikov Artem created MNG-6844:
-

 Summary: Use StandardCharsets and remove outdated @SuppressWarnings
 Key: MNG-6844
 URL: https://issues.apache.org/jira/browse/MNG-6844
 Project: Maven
  Issue Type: Improvement
  Components: General
Affects Versions: 3.6.3
Reporter: Krosheninnikov Artem


StandardCharsets.UTF_8 can be used instead of string-defined "UTF-8" and so on.

 

Also removed outdated suppressions.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-compiler-plugin] loizbak commented on issue #27: MCOMPILER-372 - fix test compile issue: added dependency test path for modules

[GitBox]

loizbak commented on issue #27: MCOMPILER-372 - fix test compile issue: added 
dependency test path for modules
URL: 
https://github.com/apache/maven-compiler-plugin/pull/27#issuecomment-571516055
 
 
   Change is commited.
   Best regards,
   François
   
   Le lun. 6 janv. 2020 à 21:03, François Loison 
   a écrit :
   
   > OK, on going.
   >
   > Le ven. 3 janv. 2020 à 21:13, Robert Scholte  a
   > écrit :
   >
   >> *@rfscholte* commented on this pull request.
   >> --
   >>
   >> In src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java
   >> 

   >> :
   >>
   >> >  }
   >>  }
   >>  }
   >>
   >> +/**
   >> + * Get module test path element from module path element
   >> + * @param modulePathElt
   >> + * @return
   >> + */
   >> +private File getModuleTestPathElt( File modulePathElt )
   >>
   >> This methods feels a bit like best guessing. It is better to loop over
   >> all the reactorProjects to find the Paths that belong to the same Maven
   >> Project (and because of that to the same module)
   >>
   >> —
   >> You are receiving this because you modified the open/close state.
   >> Reply to this email directly, view it on GitHub
   >> 
,
   >> or unsubscribe
   >> 

   >> .
   >>
   >
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure

[Paul Millar (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009517#comment-17009517
 ] 

Paul Millar commented on SUREFIRE-1719:
---

Hi Tibor,

I've tested the 3.0.0-SNAPSHOT and it works perfectly.

Thanks for all you help!
Paul.

> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2, 
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3, 
> unit tests started to fail with the message "ExecutionException The forked VM 
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl 
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{  org.apache.maven.plugins}}
> {{  maven-surefire-plugin}}
> {{  }}
> {{    }}
> {{  **/*Test.class}}
> {{  **/*Tests.class}}
> {{    }}
> {{    }}
> {{    1C}}
> {{    false}}
> {{  }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the 
> problem appear 6 out of 10 times when running the above mvn command. There is 
> (apparently) little that seems to influence whether the build will succeed or 
> fail.
> [I've attached the complete output from running the above mvn command, both 
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores. 
> Our build machine has 24 cores, and I've seen a report of a similar problem 
> where building dCache on a 48 core machine. On the other side, I have been 
> unable to reproduce the problem with my desktop machine (8 core) or on my 
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on 
> a machine with a small number of cores. However, I've noticed that, on an 8 
> core machine, increasing the forkCount does not actually result in that many 
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM 
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood 
> of a problem below 10% (0 failures with 10 builds) on our build machine.  On 
> this machine, the default configuration would try to run 24 JVM instances 
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building 
> with surefire v2.19.1, the above mvn command is always successful on our 
> build machine.  Building with surefire v2.20 results in intermittent failures 
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10 
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342 
> Acknowledge normal exit of JVM and drain shared memory between processes" is 
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it 
> introduces is somehow racy (for example, reading or updating a field-member 
> outside of a monitor) and problems are triggered if there are a large number 
> of JVMs exiting concurrently.  So, with increased number of concurrent JVMs 
> there is an increased risk of a thread loosing the race, and so triggering 
> this error.
> Such a problem would be consistent with observed behaviour.  However, I don't 
> have any strong evidence that this is what is happening.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRELEASE-1036) fix javadoc for JDK 8

[Carlos Chacin (Jira)]

[ 
https://issues.apache.org/jira/browse/MRELEASE-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009512#comment-17009512
 ] 

Carlos Chacin commented on MRELEASE-1036:
-

[~hboutemy] I would like to take care of this task, can you provide a little 
bit more of context about what is required?

[~rfscholte] Can you assign this to ticket to me?

> fix javadoc for JDK 8
> -
>
> Key: MRELEASE-1036
> URL: https://issues.apache.org/jira/browse/MRELEASE-1036
> Project: Maven Release Plugin
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 3.0.0-M1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MNG-6806) Provide Maven BOM

[Carlos Chacin (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009505#comment-17009505
 ] 

Carlos Chacin edited comment on MNG-6806 at 1/7/20 8:46 AM:


[~rfscholte] [~michael-o] is anyone taking care of this task? if the answer is 
no, can you please assign it to me?


was (Author: cchacin):
[~rfscholte][~michael-o] is anyone taking care of this task? if the answer is 
no, can you please assign it to me?

> Provide Maven BOM
> -
>
> Key: MNG-6806
> URL: https://issues.apache.org/jira/browse/MNG-6806
> Project: Maven
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.7.0-candidate
>
>
> Maven libraries should always have the same version to ensure they work as 
> expected, hence the preferred way to manage that is with a bom.
> Let's introduce the maven-bom.
> See https://www.baeldung.com/spring-maven-bom about how to write and use the 
> bom.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6806) Provide Maven BOM

[Carlos Chacin (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009505#comment-17009505
 ] 

Carlos Chacin commented on MNG-6806:


[~rfscholte][~michael-o] is anyone taking care of this task? if the answer is 
no, can you please assign it to me?

> Provide Maven BOM
> -
>
> Key: MNG-6806
> URL: https://issues.apache.org/jira/browse/MNG-6806
> Project: Maven
>  Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
>  Labels: up-for-grabs
> Fix For: 3.7.0-candidate
>
>
> Maven libraries should always have the same version to ensure they work as 
> expected, hence the preferred way to manage that is with a bom.
> Let's introduce the maven-bom.
> See https://www.baeldung.com/spring-maven-bom about how to write and use the 
> bom.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven] kodeva commented on issue #310: [MNG-6843] - Parallel build fails due to missing JAR artifacts in compilePath

[GitBox]

kodeva commented on issue #310: [MNG-6843] - Parallel build fails due to 
missing JAR artifacts in compilePath
URL: https://github.com/apache/maven/pull/310#issuecomment-571483072
 
 
   The usage of cloned MavenSession objects with shallow copy of MavenProject 
objects is not thread-safe when it comes to parallel builds because the 
MavenProjects are being modified from multiple threads. See the 
https://issues.apache.org/jira/browse/MNG-6843 issue.
   
   I don't have big insight in maven code and thus yep, this change fixes 
something while it might be breaking something different not covered by 
automated tests. And, most probably, there's another better fix for the issue.
   
   I'll try to create a project that simulates the issue deterministically and 
that can be publicly shared.


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services