[jira] [Commented] (SUREFIRE-1512) ProcessInfo for Windows is prone to timezone offset changes

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1512:


I am waiting for similar issues, for answer from SUREFIRE-1502 and I am
waiting for INFRA because I cannot rely on our Jenkins result since the
Windows machines have low free disk space.
In the GitHub pull requests are two simple fixes and improvements which are
also successful. Everything can be included in release.
I guess users in SUREFIRE-1502 are also waiting but I do not have Mac OS
and I am not able to reproduce Docker issue on Ubuntu however I tried that
using Docker CE.

On Thu, Apr 12, 2018 at 6:24 AM, Julian Reschke (JIRA) 



> ProcessInfo for Windows is prone to timezone offset changes
> ---
>
> Key: SUREFIRE-1512
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1512
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: Julian Reschke
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> For some reason, on one of my machines, the current DST offset changes 
> between calls. See 
> .
>  This will cause surefire to think the forked VM terminated, as the string 
> compare of time stamps detects a change.
> It would be good if the comparison code would actually parse the string value 
> into a DST/TZ agnostic value for comparison. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1512) ProcessInfo for Windows is prone to timezone offset changes

[Julian Reschke (JIRA)]

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

Julian Reschke commented on SUREFIRE-1512:
--

Thanks, [~tibor17]. It would be great to have that in the next release. Would 
that 2.21.1 or 3.0?

> ProcessInfo for Windows is prone to timezone offset changes
> ---
>
> Key: SUREFIRE-1512
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1512
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: Julian Reschke
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> For some reason, on one of my machines, the current DST offset changes 
> between calls. See 
> .
>  This will cause surefire to think the forked VM terminated, as the string 
> compare of time stamps detects a change.
> It would be good if the comparison code would actually parse the string value 
> into a DST/TZ agnostic value for comparison. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-5820) Allow extensions in settings.xml

[James Z.M. Gao (JIRA)]

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

James Z.M. Gao commented on MNG-5820:
-

When settings.xml parser meeting unknown tags, it seems only report a warning, 
not fail the building.

> Allow extensions in settings.xml
> 
>
> Key: MNG-5820
> URL: https://issues.apache.org/jira/browse/MNG-5820
> Project: Maven
>  Issue Type: Improvement
>  Components: Bootstrap  Build
>Affects Versions: 3.3.1
>Reporter: Yuri
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
>
> Since 3.3.1, we are now allowed to specify extensions in the 
> projectBaseDir/.mvn/extensions.xml. This is great on it's own, but I have a 
> case where repo urls are externalized to ~/.m2/settings.xml and these urls 
> require an extension. Right now, the url and the extension that goes along 
> with it are managed in two completely different places.
> Ideally, I would like to see the option to add an extension to our existing 
> ~/.m2/settings.xml.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MNG-6392) Add Project Settings .mvn/settings.xml

[James Z.M. Gao (JIRA)]

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

James Z.M. Gao updated MNG-6392:

Description: 
Maven originally have two settings slots, user and global. But the project need 
and should have more ability to control how itself built by maven. Just follow 
the core-extension way, we can add a new settings slot, project settings at 

 
{code:java}
${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
 

 

Then the settings merge order from high priority to low is
 * project level
 * user level
 * global level

This order is widely used in many projects such as git.

In the project settings, we should always ignore some _personal local_ fields, 
including localRepository, interactiveMode, offline and usePluginRegistry.

 

With this feature, many things become easy. When we developing multiply 
projects from different organizations/companies/envrionments, the maven 
configurations may conflict, and are annoying to manage (edit manually or use 
some switch scripts each time we switch the project or environment). Another 
problem is when using some corp maven repositories or mirros for bootstraping 
the team common root poms or core-extensions, the developers have to do some 
setup actions. But the projects should be `mvn verify`-ed out of box.

 

Here is a [fast implementation via 
core-extension|https://github.com/gzm55/project-settings-maven-extension], but 
this feature should woks before loading extensions.

  was:
Maven originally have two settings slot, user and global. But the project need 
and should have more ability to control how itself built by maven. Just follow 
the core-extension way, we can add a new settings slot, project settings at 

 
{code:java}
${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
 

 

Then the settings merge order from high priority to low is
 * project level
 * user level
 * global level

This order is widely used in many projects such as git.

In the project settings, we should always ignore some _personal local_ fields, 
including localRepository, interactiveMode, offline and usePluginRegistry.

 

With this feature, many things become easy. When we developing multiply 
projects from different organizations/companies/envrionments, the maven 
configurations may conflict, and are annoying to manage (edit manually or use 
some switch scripts each time we switch the project or environment). Another 
problem is when using some corp maven repositories or mirros for bootstraping 
the team common root poms or core-extensions, the developers have to do some 
setup actions. But the projects should be `mvn verify`-ed out of box.

 

Here is a [fast implementation via 
core-extension|https://github.com/gzm55/project-settings-maven-extension], but 
this feature should woks before loading extensions.


> Add Project Settings .mvn/settings.xml
> --
>
> Key: MNG-6392
> URL: https://issues.apache.org/jira/browse/MNG-6392
> Project: Maven
>  Issue Type: New Feature
>  Components: Bootstrap  Build, Settings
>Affects Versions: 3.5.3
>Reporter: James Z.M. Gao
>Priority: Major
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Maven originally have two settings slots, user and global. But the project 
> need and should have more ability to control how itself built by maven. Just 
> follow the core-extension way, we can add a new settings slot, project 
> settings at 
>  
> {code:java}
> ${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
>  
>  
> Then the settings merge order from high priority to low is
>  * project level
>  * user level
>  * global level
> This order is widely used in many projects such as git.
> In the project settings, we should always ignore some _personal local_ 
> fields, including localRepository, interactiveMode, offline and 
> usePluginRegistry.
>  
> With this feature, many things become easy. When we developing multiply 
> projects from different organizations/companies/envrionments, the maven 
> configurations may conflict, and are annoying to manage (edit manually or use 
> some switch scripts each time we switch the project or environment). Another 
> problem is when using some corp maven repositories or mirros for bootstraping 
> the team common root poms or core-extensions, the developers have to do some 
> setup actions. But the projects should be `mvn verify`-ed out of box.
>  
> Here is a [fast implementation via 
> core-extension|https://github.com/gzm55/project-settings-maven-extension], 
> but this feature should woks before loading extensions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MNG-6392) Add Project Settings .mvn/settings.xml

[James Z.M. Gao (JIRA)]

James Z.M. Gao created MNG-6392:
---

 Summary: Add Project Settings .mvn/settings.xml
 Key: MNG-6392
 URL: https://issues.apache.org/jira/browse/MNG-6392
 Project: Maven
  Issue Type: New Feature
  Components: Bootstrap  Build, Settings
Affects Versions: 3.5.3
Reporter: James Z.M. Gao


Maven originally have two settings slot, user and global. But the project need 
and should have more ability to control how itself built by maven. Just follow 
the core-extension way, we can add a new settings slot, project settings at 

 
{code:java}
${maven.multiModuleProjectDirectory}/.mvn/settings.xml{code}
 

 

Then the settings merge order from high priority to low is
 * project level
 * user level
 * global level

This order is widely used in many projects such as git.

In the project settings, we should always ignore some _personal local_ fields, 
including localRepository, interactiveMode, offline and usePluginRegistry.

 

With this feature, many things become easy. When we developing multiply 
projects from different organizations/companies/envrionments, the maven 
configurations may conflict, and are annoying to manage (edit manually or use 
some switch scripts each time we switch the project or environment). Another 
problem is when using some corp maven repositories or mirros for bootstraping 
the team common root poms or core-extensions, the developers have to do some 
setup actions. But the projects should be `mvn verify`-ed out of box.

 

Here is a [fast implementation via 
core-extension|https://github.com/gzm55/project-settings-maven-extension], but 
this feature should woks before loading extensions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1515) Standard output write fails for empty array

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1515:
--

Tibor17 commented on issue #182: [SUREFIRE-1515] Fix for use case when an empty 
array is passed.
URL: https://github.com/apache/maven-surefire/pull/182#issuecomment-380610984
 
 
   @abaxanean 
   Great job! I will push it to master soon.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Standard output write fails for empty array
> ---
>
> Key: SUREFIRE-1515
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1515
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Alexandru Baxanean
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tibor17 commented on issue #182: [SUREFIRE-1515] Fix for use case when an empty array is passed.

[GitBox]

Tibor17 commented on issue #182: [SUREFIRE-1515] Fix for use case when an empty 
array is passed.
URL: https://github.com/apache/maven-surefire/pull/182#issuecomment-380610984
 
 
   @abaxanean 
   Great job! I will push it to master soon.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] (MSHADE-284) Shaded test JARs are always empty

[Peter De Maeyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434638#comment-16434638
 ] 

Peter De Maeyer commented on MSHADE-284:


OK, that's a fair point, I'll try to do that after I familiarize myself with 
the test code.

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. 
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I 
> have tested it manually on my project and it works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380609839
 
 
   @Tibor17 created https://github.com/apache/maven-surefire/pull/182


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array

[GitBox]

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380609839
 
 
   @Tibor17 created https://github.com/apache/maven-surefire/pull/182


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380608538
 
 
   @Tibor17 created another one 
https://github.com/apache/maven-surefire/pull/181


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380609839
 
 
   created https://github.com/apache/maven-surefire/pull/182


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1515) Standard output write fails for empty array

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1515:
--

abaxanean opened a new pull request #182: [SUREFIRE-1515] Fix for use case when 
an empty array is passed.
URL: https://github.com/apache/maven-surefire/pull/182
 
 
   Fix for empty array print


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Standard output write fails for empty array
> ---
>
> Key: SUREFIRE-1515
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1515
> Project: Maven Surefire
>  Issue Type: Bug
>Reporter: Alexandru Baxanean
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array

[GitBox]

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380608538
 
 
   @Tibor17 created another one 
https://github.com/apache/maven-surefire/pull/181


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array

[GitBox]

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380609839
 
 
   created https://github.com/apache/maven-surefire/pull/182


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] abaxanean opened a new pull request #182: [SUREFIRE-1515] Fix for use case when an empty array is passed.

[GitBox]

abaxanean opened a new pull request #182: [SUREFIRE-1515] Fix for use case when 
an empty array is passed.
URL: https://github.com/apache/maven-surefire/pull/182
 
 
   Fix for empty array print


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean closed pull request #181: SUREFIRE-1454 Fix for use case when an 
empty array is passed.
URL: https://github.com/apache/maven-surefire/pull/181
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
 
b/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
index 23d372c75..b0665bd1e 100644
--- 
a/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
+++ 
b/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
@@ -239,6 +239,10 @@ else if ( ch >= 'A' )
 public static EncodedArray escapeBytesToPrintable( final byte[] header, 
final byte[] input, final int off,
final int len )
 {
+if ( input.length == 0 )
+{
+return EncodedArray.EMPTY;
+}
 if ( off < 0 || len < 0 || off >= input.length || len > input.length 
|| off > len )
 {
 throw new IndexOutOfBoundsException(
@@ -359,6 +363,8 @@ public static boolean startsWith( StringBuffer buffer, 
String pattern )
  */
 public static final class EncodedArray
 {
+private static final EncodedArray EMPTY = new EncodedArray( new 
byte[]{}, 0 );
+
 private final byte[] array;
 private final int size;
 
diff --git 
a/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
 
b/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
index dea6c9b1a..96e5ed31a 100644
--- 
a/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
+++ 
b/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
@@ -110,4 +110,13 @@ public void testEscapeWithHeader()
 
 assertArrayEquals( expectedResult, actualResult );
 }
+
+public void testEmptyByteArray()
+{
+byte[] header = { (byte) 'a' };
+byte[] input = {};
+EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( 
header, input, 0, input.length );
+assertEquals( 0, encodedArray.getSize() );
+assertEquals( 0, encodedArray.getArray().length );
+}
 }


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] abaxanean closed pull request #181: SUREFIRE-1454 Fix for use case when an empty array is passed.

[GitBox]

abaxanean closed pull request #181: SUREFIRE-1454 Fix for use case when an 
empty array is passed.
URL: https://github.com/apache/maven-surefire/pull/181
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
 
b/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
index 23d372c75..b0665bd1e 100644
--- 
a/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
+++ 
b/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
@@ -239,6 +239,10 @@ else if ( ch >= 'A' )
 public static EncodedArray escapeBytesToPrintable( final byte[] header, 
final byte[] input, final int off,
final int len )
 {
+if ( input.length == 0 )
+{
+return EncodedArray.EMPTY;
+}
 if ( off < 0 || len < 0 || off >= input.length || len > input.length 
|| off > len )
 {
 throw new IndexOutOfBoundsException(
@@ -359,6 +363,8 @@ public static boolean startsWith( StringBuffer buffer, 
String pattern )
  */
 public static final class EncodedArray
 {
+private static final EncodedArray EMPTY = new EncodedArray( new 
byte[]{}, 0 );
+
 private final byte[] array;
 private final int size;
 
diff --git 
a/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
 
b/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
index dea6c9b1a..96e5ed31a 100644
--- 
a/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
+++ 
b/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
@@ -110,4 +110,13 @@ public void testEscapeWithHeader()
 
 assertArrayEquals( expectedResult, actualResult );
 }
+
+public void testEmptyByteArray()
+{
+byte[] header = { (byte) 'a' };
+byte[] input = {};
+EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( 
header, input, 0, input.length );
+assertEquals( 0, encodedArray.getSize() );
+assertEquals( 0, encodedArray.getArray().length );
+}
 }


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380608538
 
 
   @Tibor17 created another one 
https://github.com/apache/maven-surefire/pull/181


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean opened a new pull request #181: SUREFIRE-1454 Fix for use case when 
an empty array is passed.
URL: https://github.com/apache/maven-surefire/pull/181
 
 
   Empty array print fix


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] abaxanean opened a new pull request #181: SUREFIRE-1454 Fix for use case when an empty array is passed.

[GitBox]

abaxanean opened a new pull request #181: SUREFIRE-1454 Fix for use case when 
an empty array is passed.
URL: https://github.com/apache/maven-surefire/pull/181
 
 
   Empty array print fix


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array

[GitBox]

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380608538
 
 
   @Tibor17 created another one 
https://github.com/apache/maven-surefire/pull/181


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean closed pull request #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
 
b/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
index 23d372c75..b0665bd1e 100644
--- 
a/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
+++ 
b/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
@@ -239,6 +239,10 @@ else if ( ch >= 'A' )
 public static EncodedArray escapeBytesToPrintable( final byte[] header, 
final byte[] input, final int off,
final int len )
 {
+if ( input.length == 0 )
+{
+return EncodedArray.EMPTY;
+}
 if ( off < 0 || len < 0 || off >= input.length || len > input.length 
|| off > len )
 {
 throw new IndexOutOfBoundsException(
@@ -359,6 +363,8 @@ public static boolean startsWith( StringBuffer buffer, 
String pattern )
  */
 public static final class EncodedArray
 {
+private static final EncodedArray EMPTY = new EncodedArray( new 
byte[]{}, 0 );
+
 private final byte[] array;
 private final int size;
 
diff --git 
a/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
 
b/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
index dea6c9b1a..96e5ed31a 100644
--- 
a/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
+++ 
b/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
@@ -110,4 +110,13 @@ public void testEscapeWithHeader()
 
 assertArrayEquals( expectedResult, actualResult );
 }
+
+public void testEmptyByteArray()
+{
+byte[] header = { (byte) 'a' };
+byte[] input = {};
+EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( 
header, input, 0, input.length );
+assertEquals( 0, encodedArray.getSize() );
+assertEquals( 0, encodedArray.getArray().length );
+}
 }


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] abaxanean closed pull request #180: SUREFIRE-1454 fix for empty array

[GitBox]

abaxanean closed pull request #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
 
b/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
index 23d372c75..b0665bd1e 100644
--- 
a/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
+++ 
b/surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java
@@ -239,6 +239,10 @@ else if ( ch >= 'A' )
 public static EncodedArray escapeBytesToPrintable( final byte[] header, 
final byte[] input, final int off,
final int len )
 {
+if ( input.length == 0 )
+{
+return EncodedArray.EMPTY;
+}
 if ( off < 0 || len < 0 || off >= input.length || len > input.length 
|| off > len )
 {
 throw new IndexOutOfBoundsException(
@@ -359,6 +363,8 @@ public static boolean startsWith( StringBuffer buffer, 
String pattern )
  */
 public static final class EncodedArray
 {
+private static final EncodedArray EMPTY = new EncodedArray( new 
byte[]{}, 0 );
+
 private final byte[] array;
 private final int size;
 
diff --git 
a/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
 
b/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
index dea6c9b1a..96e5ed31a 100644
--- 
a/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
+++ 
b/surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
@@ -110,4 +110,13 @@ public void testEscapeWithHeader()
 
 assertArrayEquals( expectedResult, actualResult );
 }
+
+public void testEmptyByteArray()
+{
+byte[] header = { (byte) 'a' };
+byte[] input = {};
+EncodedArray encodedArray = StringUtils.escapeBytesToPrintable( 
header, input, 0, input.length );
+assertEquals( 0, encodedArray.getSize() );
+assertEquals( 0, encodedArray.getArray().length );
+}
 }


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] (SUREFIRE-1515) Standard output write fails for empty array

[Alexandru Baxanean (JIRA)]

Alexandru Baxanean created SUREFIRE-1515:


 Summary: Standard output write fails for empty array
 Key: SUREFIRE-1515
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1515
 Project: Maven Surefire
  Issue Type: Bug
Reporter: Alexandru Baxanean






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

Tibor17 commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380607051
 
 
   SUREFIRE-1454 was closed. We should have new one. Pls do this as well and 
rename the commit message to
   [SUREFIRE-12345] msg
   Basically brackets around jira id.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tibor17 commented on issue #180: SUREFIRE-1454 fix for empty array

[GitBox]

Tibor17 commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380607051
 
 
   SUREFIRE-1454 was closed. We should have new one. Pls do this as well and 
rename the commit message to
   [SUREFIRE-12345] msg
   Basically brackets around jira id.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380606051
 
 
   @Tibor17 done


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array

[GitBox]

abaxanean commented on issue #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180#issuecomment-380606051
 
 
   @Tibor17 done


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

Tibor17 commented on a change in pull request #180: SUREFIRE-1454 fix for empty 
array
URL: https://github.com/apache/maven-surefire/pull/180#discussion_r180906907
 
 

 ##
 File path: 
surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
 ##
 @@ -110,4 +110,12 @@ public void testEscapeWithHeader()
 
 assertArrayEquals( expectedResult, actualResult );
 }
+
+public void testEmptyByteArray() {
 
 Review comment:
   Pls put the bracket '{' on new line as we have in other main code.
   Amend the previous commit means we should have single commit per 
fix/feature. Thx.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] Tibor17 commented on a change in pull request #180: SUREFIRE-1454 fix for empty array

[GitBox]

Tibor17 commented on a change in pull request #180: SUREFIRE-1454 fix for empty 
array
URL: https://github.com/apache/maven-surefire/pull/180#discussion_r180906907
 
 

 ##
 File path: 
surefire-api/src/test/java/org/apache/maven/surefire/util/internal/StringUtilsTest.java
 ##
 @@ -110,4 +110,12 @@ public void testEscapeWithHeader()
 
 assertArrayEquals( expectedResult, actualResult );
 }
+
+public void testEmptyByteArray() {
 
 Review comment:
   Pls put the bracket '{' on new line as we have in other main code.
   Amend the previous commit means we should have single commit per 
fix/feature. Thx.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] (MASSEMBLY-883) Transitive dependencies with scope provided are included with jar-with-dependencies descriptor

[Francois Armand (JIRA)]

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

Francois Armand updated MASSEMBLY-883:
--
Description: 
In the following case as shown by {{mvn dependency:tree}}, with the predifined 
descriptor {{jar-with-dependencies}}:

 

{{[INFO] +- com.jayway.jsonpath:json-path:jar:2.2.0:compile}}
{{[INFO] | +- net.minidev:json-smart:jar:2.2.1:compile}}
{{[INFO] | | - net.minidev:accessors-smart:jar:1.1:compile}}
{{[INFO] | - org.slf4j:slf4j-api:jar:1.7.16:provided}}
  

{{json-path}}, {{json-smart}}, {{accessors-smart}} are included, as expected. 

{{But slf4j-api}} is also included in the resulting jar.

Other direct dependencies with scope `provided` are correctly excluded from the 
final jar.

If this is the intendented behavior, which is highly surprising, could you 
document it in the corresponding descriptor documentation 
([http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies).]
 Could you also explain what descriptor would allow to achieve the desired 
behavior (or point to a resource explaining it, I wasn't able to find one).

Thanks.
  

  was:
In the following case as shown by {{mvn dependency:tree}}{{, with the 
predifined descriptor `jar-with-dependencies`:}}
 
{{[INFO] +- com.jayway.jsonpath:json-path:jar:2.2.0:compile }}
{{[INFO] | +- net.minidev:json-smart:jar:2.2.1:compile }}
{{[INFO] | | \- net.minidev:accessors-smart:jar:1.1:compile }}
{{[INFO] | \- org.slf4j:slf4j-api:jar:1.7.16:provided}}
 

{{json-path}}, {{json-smart}}, {{accessors-smart }}are included, as expected.  

{{But }}{{slf4j-api}} is also included in the resulting jar.

Other direct dependencies with scope `provided` are correctly excluded from the 
final jar.

If this is the intendented behavior, which is highly surprising, could you 
document it in the corresponding descriptor documentation 
([http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies).]
 Could you also explain what descriptor would allow to achieve the desired 
behavior (or point to a resource explaining it, I wasn't able to find one).

Thanks.
 


> Transitive dependencies with scope provided are included with 
> jar-with-dependencies descriptor
> --
>
> Key: MASSEMBLY-883
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-883
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>  Components: predefined descriptors
>Affects Versions: 3.1.0
>Reporter: Francois Armand
>Priority: Major
>
> In the following case as shown by {{mvn dependency:tree}}, with the 
> predifined descriptor {{jar-with-dependencies}}:
>  
> {{[INFO] +- com.jayway.jsonpath:json-path:jar:2.2.0:compile}}
> {{[INFO] | +- net.minidev:json-smart:jar:2.2.1:compile}}
> {{[INFO] | | - net.minidev:accessors-smart:jar:1.1:compile}}
> {{[INFO] | - org.slf4j:slf4j-api:jar:1.7.16:provided}}
>   
> {{json-path}}, {{json-smart}}, {{accessors-smart}} are included, as expected. 
> {{But slf4j-api}} is also included in the resulting jar.
> Other direct dependencies with scope `provided` are correctly excluded from 
> the final jar.
> If this is the intendented behavior, which is highly surprising, could you 
> document it in the corresponding descriptor documentation 
> ([http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies).]
>  Could you also explain what descriptor would allow to achieve the desired 
> behavior (or point to a resource explaining it, I wasn't able to find one).
> Thanks.
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1454) Speedup Standard Output if Tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SUREFIRE-1454:
--

abaxanean opened a new pull request #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180
 
 
   Fix for use case when an empty array is passed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] abaxanean opened a new pull request #180: SUREFIRE-1454 fix for empty array

[GitBox]

abaxanean opened a new pull request #180: SUREFIRE-1454 fix for empty array
URL: https://github.com/apache/maven-surefire/pull/180
 
 
   Fix for use case when an empty array is passed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] (MASSEMBLY-883) Transitive dependencies with scope provided are included with jar-with-dependencies descriptor

[Francois Armand (JIRA)]

Francois Armand created MASSEMBLY-883:
-

 Summary: Transitive dependencies with scope provided are included 
with jar-with-dependencies descriptor
 Key: MASSEMBLY-883
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-883
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: predefined descriptors
Affects Versions: 3.1.0
Reporter: Francois Armand


In the following case as shown by {{mvn dependency:tree}}{{, with the 
predifined descriptor `jar-with-dependencies`:}}
 
{{[INFO] +- com.jayway.jsonpath:json-path:jar:2.2.0:compile }}
{{[INFO] | +- net.minidev:json-smart:jar:2.2.1:compile }}
{{[INFO] | | \- net.minidev:accessors-smart:jar:1.1:compile }}
{{[INFO] | \- org.slf4j:slf4j-api:jar:1.7.16:provided}}
 

{{json-path}}, {{json-smart}}, {{accessors-smart }}are included, as expected.  

{{But }}{{slf4j-api}} is also included in the resulting jar.

Other direct dependencies with scope `provided` are correctly excluded from the 
final jar.

If this is the intendented behavior, which is highly surprising, could you 
document it in the corresponding descriptor documentation 
([http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies).]
 Could you also explain what descriptor would allow to achieve the desired 
behavior (or point to a resource explaining it, I wasn't able to find one).

Thanks.
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (SUREFIRE-1512) ProcessInfo for Windows is prone to timezone offset changes

[Tibor Digana (JIRA)]

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

Tibor Digana closed SUREFIRE-1512.
--
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c546235573817a32155b0413029b4d0a8b1f80d6

> ProcessInfo for Windows is prone to timezone offset changes
> ---
>
> Key: SUREFIRE-1512
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1512
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.21.0
>Reporter: Julian Reschke
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> For some reason, on one of my machines, the current DST offset changes 
> between calls. See 
> .
>  This will cause surefire to think the forked VM terminated, as the string 
> compare of time stamps detects a change.
> It would be good if the comparison code would actually parse the string value 
> into a DST/TZ agnostic value for comparison. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SUREFIRE-1502) Forking fails on OS/X

[Tibor Digana (JIRA)]

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

Tibor Digana edited comment on SUREFIRE-1502 at 4/11/18 8:43 PM:
-

[~larry_west]
Larry, I created a docker project but it does not crash. It just runs 3 
seconds. I tried several times.
Can you please use my sources and tell me what's different with your use case 
on your system?

{code:bash}
sudo docker build --no-cache -t mymvn:1 -f ./Dockerfile .
sudo docker run -it --rm mymvn:1 /bin/sh
{code}

Run the command {{mvn test}} in the shell console of docker.

{{Dockerfile}}
{code:bash}
FROM maven:3.5.3-jdk-8-alpine
COPY ./. /
{code}

{{src/test/java/MyTest.java}}
{code:java}
import org.junit.Test;

public class MyTest {
@Test
public void test() throws InterruptedException {
Thread.sleep(3000L);
}
} 
{code}

{{pom.xml}}
{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

x
x
1.0



junit
junit
4.12






maven-surefire-plugin
2.21.0






{code}



was (Author: tibor17):
[~larry_west]
Larry, I created a docker project but it does not crash. It just runs 3 second. 
I tried several times.
Can you please use my sources and tell me what's different with your use case 
on your system?

{code:bash}
sudo docker build --no-cache -t mymvn:1 -f ./Dockerfile .
sudo docker run -it --rm mymvn:1 /bin/sh
{code}

Run the command {{mvn test}} in the shell console of docker.

{{Dockerfile}}
{code:bash}
FROM maven:3.5.3-jdk-8-alpine
COPY ./. /
{code}

{{src/test/java/MyTest.java}}
{code:java}
import org.junit.Test;

public class MyTest {
@Test
public void test() throws InterruptedException {
Thread.sleep(3000L);
}
} 
{code}

{{pom.xml}}
{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

x
x
1.0



junit
junit
4.12






maven-surefire-plugin
2.21.0






{code}


> Forking fails on OS/X
> -
>
> Key: SUREFIRE-1502
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1502
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1, 2.21.0
> Environment: OS/X 10.13.3
> Java 1.8.0_162
>Reporter: Larry West
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire3972773662020453876tmp, 
> surefire_06790995305937656848tmp
>
>
> This is very similar to SUREFIRE-1422, but is still present _intermittently_ 
> on version 2.21.0 as well as 2.20.1.  It was not present on 2.19.1.
> The symptom is that all tests run fine (the reports are there), but as soon 
> as they do, there is an error:
> {noformat}
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
>  ...
> Process Exit Code: 0
> {noformat}
> This of course fails the build.
> This occurs on roughly half the builds (with 2.21.0, at least).
> Maven version 3.5.3. Java 1.8.0_162. OS/X 10.13.3.
> h5. Selected output from mvn -X
> {noformat}
> [DEBUG] Forking command line: /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> {noformat}
> ... then, after all the tests have run, successfully, it reports failure:
> {noformat}
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> Command was /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> Process Exit Code: 0
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork 
> (ForkStarter.java:671)
> at 

[jira] [Comment Edited] (SUREFIRE-1502) Forking fails on OS/X

[Tibor Digana (JIRA)]

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

Tibor Digana edited comment on SUREFIRE-1502 at 4/11/18 8:42 PM:
-

[~larry_west]
Larry, I created a docker project but it does not crash. It just runs 3 second. 
I tried several times.
Can you please use my sources and tell me what's different with your use case 
on your system?

{code:bash}
sudo docker build --no-cache -t mymvn:1 -f ./Dockerfile .
sudo docker run -it --rm mymvn:1 /bin/sh
{code}

Run the command {{mvn test}} in the shell console of docker.

{{Dockerfile}}
{code:bash}
FROM maven:3.5.3-jdk-8-alpine
COPY ./. /
{code}

{{src/test/java/MyTest.java}}
{code:java}
import org.junit.Test;

public class MyTest {
@Test
public void test() throws InterruptedException {
Thread.sleep(3000L);
}
} 
{code}

{{pom.xml}}
{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

x
x
1.0



junit
junit
4.12






maven-surefire-plugin
2.21.0






{code}



was (Author: tibor17):
[~larry_west]
Larry, I created a docker project but it does not crash. It just runs 3 second. 
I tried several times.
Can you please use my sources and tell me what's different with your use case 
on your system?

{code:shell}
sudo docker build --no-cache -t mymvn:1 -f ./Dockerfile .
sudo docker run -it --rm mymvn:1 /bin/sh
{code}

Run the command {{mvn test}} in the shell console of docker.

{{Dockerfile}}
{code:shell}
FROM maven:3.5.3-jdk-8-alpine
COPY ./. /
{code}

{{src/test/java/MyTest.java}}
{code:java}
import org.junit.Test;

public class MyTest {
@Test
public void test() throws InterruptedException {
Thread.sleep(3000L);
}
} 
{code}

{{pom.xml}}

{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

x
x
1.0



junit
junit
4.12






maven-surefire-plugin
2.21.0






{code}


> Forking fails on OS/X
> -
>
> Key: SUREFIRE-1502
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1502
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1, 2.21.0
> Environment: OS/X 10.13.3
> Java 1.8.0_162
>Reporter: Larry West
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire3972773662020453876tmp, 
> surefire_06790995305937656848tmp
>
>
> This is very similar to SUREFIRE-1422, but is still present _intermittently_ 
> on version 2.21.0 as well as 2.20.1.  It was not present on 2.19.1.
> The symptom is that all tests run fine (the reports are there), but as soon 
> as they do, there is an error:
> {noformat}
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
>  ...
> Process Exit Code: 0
> {noformat}
> This of course fails the build.
> This occurs on roughly half the builds (with 2.21.0, at least).
> Maven version 3.5.3. Java 1.8.0_162. OS/X 10.13.3.
> h5. Selected output from mvn -X
> {noformat}
> [DEBUG] Forking command line: /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> {noformat}
> ... then, after all the tests have run, successfully, it reports failure:
> {noformat}
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> Command was /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> Process Exit Code: 0
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork 
> (ForkStarter.java:671)
> at 

[jira] [Commented] (SUREFIRE-1502) Forking fails on OS/X

[Tibor Digana (JIRA)]

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

Tibor Digana commented on SUREFIRE-1502:


[~larry_west]
Larry, I created a docker project but it does not crash. It just runs 3 second. 
I tried several times.
Can you please use my sources and tell me what's different with your use case 
on your system?

{code:shell}
sudo docker build --no-cache -t mymvn:1 -f ./Dockerfile .
sudo docker run -it --rm mymvn:1 /bin/sh
{code}

Run the command {{mvn test}} in the shell console of docker.

{{Dockerfile}}
{code:shell}
FROM maven:3.5.3-jdk-8-alpine
COPY ./. /
{code}

{{src/test/java/MyTest.java}}
{code:java}
import org.junit.Test;

public class MyTest {
@Test
public void test() throws InterruptedException {
Thread.sleep(3000L);
}
} 
{code}

{{pom.xml}}

{code:xml}

http://maven.apache.org/POM/4.0.0;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0

x
x
1.0



junit
junit
4.12






maven-surefire-plugin
2.21.0






{code}


> Forking fails on OS/X
> -
>
> Key: SUREFIRE-1502
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1502
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: process forking
>Affects Versions: 2.20.1, 2.21.0
> Environment: OS/X 10.13.3
> Java 1.8.0_162
>Reporter: Larry West
>Assignee: Tibor Digana
>Priority: Major
> Attachments: surefire3972773662020453876tmp, 
> surefire_06790995305937656848tmp
>
>
> This is very similar to SUREFIRE-1422, but is still present _intermittently_ 
> on version 2.21.0 as well as 2.20.1.  It was not present on 2.19.1.
> The symptom is that all tests run fine (the reports are there), but as soon 
> as they do, there is an error:
> {noformat}
> The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
>  ...
> Process Exit Code: 0
> {noformat}
> This of course fails the build.
> This occurs on roughly half the builds (with 2.21.0, at least).
> Maven version 3.5.3. Java 1.8.0_162. OS/X 10.13.3.
> h5. Selected output from mvn -X
> {noformat}
> [DEBUG] Forking command line: /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> {noformat}
> ... then, after all the tests have run, successfully, it reports failure:
> {noformat}
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> Command was /bin/sh -c cd /Users/lwest/git/caas/jsk-cc && 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/jre/bin/java 
> -jar 
> /Users/lwest/git/caas/jsk-cc/target/surefire/surefirebooter4496843559994461722.jar
>  /Users/lwest/git/caas/jsk-cc/target/surefire 2018-03-16T16-08-09_300-jvmRun1 
> surefire3972773662020453876tmp surefire_06790995305937656848tmp
> Process Exit Code: 0
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork 
> (ForkStarter.java:671)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork 
> (ForkStarter.java:533)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run 
> (ForkStarter.java:278)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run 
> (ForkStarter.java:244)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider 
> (AbstractSurefireMojo.java:1148)
> at 
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
>  (AbstractSurefireMojo.java:977)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute 
> (AbstractSurefireMojo.java:853)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
> (MojoExecutor.java:146)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> (LifecycleModuleBuilder.java:117)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
> 

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434428#comment-16434428
 ] 

Hudson commented on MNGSITE-332:


Build unstable in Jenkins: Maven TLP » maven-javadoc-plugin » master #33

See 
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/33/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434419#comment-16434419
 ] 

Hudson commented on MNGSITE-332:


Build succeeded in Jenkins: Maven TLP » maven-ear-plugin » master #30

See https://builds.apache.org/job/maven-box/job/maven-ear-plugin/job/master/30/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434417#comment-16434417
 ] 

Hudson commented on MNGSITE-332:


Build succeeded in Jenkins: Maven TLP » maven-gpg-plugin » master #9

See https://builds.apache.org/job/maven-box/job/maven-gpg-plugin/job/master/9/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-284) Shaded test JARs are always empty

[Sean Busbey (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434412#comment-16434412
 ] 

Sean Busbey commented on MSHADE-284:


Hi [~peterdm]! I'm not a committer on the project, but in my experience you'll 
need to add a test that can show the impact of your fix (i.e. that fails 
without it and succeeds with it). AFAICT that's almost always a jira-specific 
it added in {{src/it/}}

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. 
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I 
> have tested it manually on my project and it works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434410#comment-16434410
 ] 

Hudson commented on MNGSITE-332:


Build succeeded in Jenkins: Maven TLP » maven-resources-plugin » master #10

See 
https://builds.apache.org/job/maven-box/job/maven-resources-plugin/job/master/10/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434381#comment-16434381
 ] 

Hudson commented on MNGSITE-332:


Build succeeded in Jenkins: Maven TLP » maven-dependency-plugin » master #13

See 
https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/13/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434382#comment-16434382
 ] 

Hudson commented on MNGSITE-332:


Build succeeded in Jenkins: Maven TLP » maven-docck-plugin » master #3

See https://builds.apache.org/job/maven-box/job/maven-docck-plugin/job/master/3/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MEJB-120) Upgrade mave-surefire/failsafe-plugin 2.21.0

[Karl Heinz Marbaise (JIRA)]

Karl Heinz Marbaise created MEJB-120:


 Summary: Upgrade mave-surefire/failsafe-plugin 2.21.0
 Key: MEJB-120
 URL: https://issues.apache.org/jira/browse/MEJB-120
 Project: Maven EJB Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.1
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.1






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434370#comment-16434370
 ] 

Hudson commented on MNGSITE-332:


Build failed in Jenkins: Maven TLP » maven-ejb-plugin » master #4

See https://builds.apache.org/job/maven-box/job/maven-ejb-plugin/job/master/4/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1454) Speedup Standard Output if Tests

[Alexandru Baxanean (JIRA)]

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

Alexandru Baxanean commented on SUREFIRE-1454:
--

 

Printing an empty array fails now
{code:java}
System.out.write(new byte[]{}){code}
 

> Speedup Standard Output if Tests
> 
>
> Key: SUREFIRE-1454
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1454
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.21.0
>
>
> Currently, surefire creates a new byte array with size of the input *3 for 
> saving the unescaped input. This made surefire way slower than running a test 
> directly in eclipse or with gradle, if it used standardout or error heavily.
> By using a list for saving the elements and converting them to an array 
> afterwards, this problem is solved, and stdout-heavy surefire tests get 
> faster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MDEPLOY-235) Upgrade mave-surefire/failsafe-plugin 2.21.0

[Karl Heinz Marbaise (JIRA)]

Karl Heinz Marbaise created MDEPLOY-235:
---

 Summary: Upgrade mave-surefire/failsafe-plugin 2.21.0
 Key: MDEPLOY-235
 URL: https://issues.apache.org/jira/browse/MDEPLOY-235
 Project: Maven Deploy Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNGSITE-332) Changed download templates of plugins not to reference .md5 anymore

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434339#comment-16434339
 ] 

Hudson commented on MNGSITE-332:


Build succeeded in Jenkins: Maven TLP » maven-checkstyle-plugin » master #18

See 
https://builds.apache.org/job/maven-box/job/maven-checkstyle-plugin/job/master/18/

> Changed download templates of plugins not to reference .md5 anymore
> ---
>
> Key: MNGSITE-332
> URL: https://issues.apache.org/jira/browse/MNGSITE-332
> Project: Maven Project Web Site
>  Issue Type: Task
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Currently we have links to md5 checksums for the plugin download pages this 
> has to be changed into links to {{sha1}} and {{sha256}} instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MDOAP-51) Upgrade mave-surefire/failsafe-plugin 2.21.0

[Karl Heinz Marbaise (JIRA)]

Karl Heinz Marbaise created MDOAP-51:


 Summary: Upgrade mave-surefire/failsafe-plugin 2.21.0
 Key: MDOAP-51
 URL: https://issues.apache.org/jira/browse/MDOAP-51
 Project: Maven DOAP Plugin
  Issue Type: Dependency upgrade
Affects Versions: 3.0.0
Reporter: Karl Heinz Marbaise
Assignee: Karl Heinz Marbaise
 Fix For: 3.0.0






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise commented on MNG-6391:
--

You had the same idea in mind as I had...sure makes sense...

> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version 
> printout but also the last built module.
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib  SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the 
> version printout.
> Also this is not the order I configured the modules in the parent pom but I 
> think this could be something on my side.
> {code:java}
> 
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MNG-6391:
-

Maybe time for better outlining, like
{noformat}
[INFO] 
[INFO] Version: 4.0.0-SNAPSHOT
[INFO] Total time:  01:45 min
[INFO] Finished at: 2018-04-11T09:56:21+02:00
[INFO] 
{noformat}

> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version 
> printout but also the last built module.
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib  SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the 
> version printout.
> Also this is not the order I configured the modules in the parent pom but I 
> think this could be something on my side.
> {code:java}
> 
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise commented on MNG-6391:
--

Agreed to your suggestion making it the first line like this:
{code}
[INFO] 
[INFO] Version: 4.0.0-SNAPSHOT
[INFO] Total time: 01:45 min
[INFO] Finished at: 2018-04-11T09:56:21+02:00
[INFO] 
{code}


> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version 
> printout but also the last built module.
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib  SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the 
> version printout.
> Also this is not the order I configured the modules in the parent pom but I 
> think this could be something on my side.
> {code:java}
> 
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (MDEPLOY-234) Nothing is deployed if deployAtEnd=true and extension is added in submodule

[Robert Scholte (JIRA)]

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

Robert Scholte closed MDEPLOY-234.
--
Resolution: Duplicate
  Assignee: Robert Scholte

I'm going to close this as duplicate. MDEPLOY-226 is the main issue related to 
the experimental deployAtEnd-option and which might have a good fix for it.

> Nothing is deployed if deployAtEnd=true  and extension is added in submodule
> 
>
> Key: MDEPLOY-234
> URL: https://issues.apache.org/jira/browse/MDEPLOY-234
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 2.8.2
> Environment: Maven 3.5.3
>Reporter: Piotr Paczynski
>Assignee: Robert Scholte
>Priority: Major
> Attachments: project.zip, result.txt
>
>
> It seems that when *deploytEnd=true* and one of the submodules in the reactor 
> adds an *extension*, then nothing gets deployed. The last module to build 
> says "Deploying ... at end".
>  
> I'm attaching a minimal project that is affected by the issue. To reproduce, 
> unpack it and issue the following command in the main dir (I've used Maven 
> 3.5.3).
> {noformat}
> mvn deploy -DaltDeploymentRepository=test::default::file:target/repo
> {noformat}
> Outcome: Nothing is deployed. The *target/repo* is not created. See output 
> attached.
> Expected result: Deployment of both modules is performed during submodule's 
> deploy phase.
>  
> I've debugged it and think I understand the problem:
> 1. When the parent module is built, the DeployMojo class is loaded and the
> {noformat}
> private static final AtomicInteger readyProjectsCounter
> {noformat}
> field is initialized to 0.
> 2. Then it's bumped to 1 when deploy of "parent" is executed.
> 3. Then, the second module is built (submodule) and, because it contributes 
> an extension, DepoyMojo class is re-loaded (by Guice?) and the
> {noformat}
> private static final AtomicInteger readyProjectsCounter{noformat}
> field is reinitialized to 0.
> 4. Then it's bumped to 1 when deploy of "submodule" is executed, but since *1 
> < 2* the deploy is not performed at all.
>  
> Not sure how to fix it, anyone?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build

[Robert Scholte (JIRA)]

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

Robert Scholte commented on MNG-6391:
-

I agree that adding version to the last section is the best. How about making 
Version the first line, followed by Total time and Finished at? I expect that 
it'll look a bit more natural compared to the current lines.

> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version 
> printout but also the last built module.
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib  SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the 
> version printout.
> Also this is not the order I configured the modules in the parent pom but I 
> think this could be something on my side.
> {code:java}
> 
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1480) parallel tests may produce invalid .xml report

[Mark Lehky (JIRA)]

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

Mark Lehky commented on SUREFIRE-1480:
--

I updated my failsafe-plugin to latest (2.21.0) a few days ago and have not 
seen this problem since. Maybe one of the surefire dependencies got updated? In 
any case, I do not believe there is a point in pursuing this any further?

Perhaps [~hwentzke] has similar results?

> parallel tests may produce invalid .xml report
> --
>
> Key: SUREFIRE-1480
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1480
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.7+ (parallel) support, Maven Failsafe Plugin, 
> Maven Surefire Plugin
>Affects Versions: 2.20.1
>Reporter: Mark Lehky
>Priority: Major
> Attachments: FailedXMLReport.txt, Stacktrace_failedTest.txt
>
>
> Relevant software:
>  * Jenkins 2.108
>  * Maven 3.??
>  * JUnit 4.12
>  * maven-failsafe-plugin 2.20.1 (I have seen this issue with surefire as well)
> I have a testsuite (one JUnit class) that contains multiple tests (multiple 
> JUnit methods), which are all run in parallel. Some of the tests may be 
> ignore using JUnit {{Assume}}.
> On occasion (not 100% reproducible), the resulting report will contain an 
> entry like:
> {noformat}
> < message="Skip test!">
> {noformat}
> The correct entry, as is produced most of the time, should be:
> {noformat}
> 
> {noformat}
> The invalid formatted XML, when run in Jenkins, results in the test being 
> flagged as failed, and Jenkins simply has the message: 
> "TEST-xml.[failed-to-read]" (the dots are replaced with the correct 
> filename!).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SCM-869) gitexe list() implemented incorrectly

[Ilya Basin (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433793#comment-16433793
 ] 

Ilya Basin commented on SCM-869:


I've updated the pull request to completely unimplement the list() method. Now 
the default implementation in AbstractScmProvider will throw 
NoSuchCommandScmException

> gitexe list() implemented incorrectly
> -
>
> Key: SCM-869
> URL: https://issues.apache.org/jira/browse/SCM-869
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-gitexe
>Affects Versions: 1.9.5, 1.9.6
>Reporter: Ilya Basin
>Priority: Major
>
> Taking the Svn implementation as a model, ScmProvider.list() should be 
> implemented as follows:
>  * The command must directly query the remote repository for files
>  * A local working copy is unnecessary and if it doesn't exist, the remote 
> repository must not be checked out.
>  * fileSet.getBasedir() indicates where to run the scm binary. The 
> recommended value is ".".
>  * fileSet.getFileList() indicates the files to list
>  * repository indicates the repo URL
> Git (among other SCMs) does not support listing remote files, so the command 
> should just fail.
> For listing files in a working copy, users should call the 
> ScmProvider.status() method instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MDEPLOY-234) Nothing is deployed if deployAtEnd=true and extension is added in submodule

[Piotr Paczynski (JIRA)]

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

Piotr Paczynski updated MDEPLOY-234:

Description: 
It seems that when *deploytEnd=true* and one of the submodules in the reactor 
adds an *extension*, then nothing gets deployed. The last module to build says 
"Deploying ... at end".

 

I'm attaching a minimal project that is affected by the issue. To reproduce, 
unpack it and issue the following command in the main dir (I've used Maven 
3.5.3).
{noformat}
mvn deploy -DaltDeploymentRepository=test::default::file:target/repo
{noformat}
Outcome: Nothing is deployed. The *target/repo* is not created. See output 
attached.

Expected result: Deployment of both modules is performed during submodule's 
deploy phase.

 

I've debugged it and think I understand the problem:

1. When the parent module is built, the DeployMojo class is loaded and the
{noformat}
private static final AtomicInteger readyProjectsCounter
{noformat}
field is initialized to 0.

2. Then it's bumped to 1 when deploy of "parent" is executed.

3. Then, the second module is built (submodule) and, because it contributes an 
extension, DepoyMojo class is re-loaded (by Guice?) and the
{noformat}
private static final AtomicInteger readyProjectsCounter{noformat}
field is reinitialized to 0.

4. Then it's bumped to 1 when deploy of "submodule" is executed, but since *1 < 
2* the deploy is not performed at all.

 

Not sure how to fix it, anyone?

  was:
It seems that when *deploytEnd=true* and one of the submodules in the reactor 
adds an *extension*, then nothing gets deployed. The last module to built says 
"Deploying ... at end".

 

I'm attaching a minimal project that is affected by the issue. To reproduce, 
unpack it and issue the following command in the main dir (I've used Maven 
3.5.3).
{noformat}
mvn deploy -DaltDeploymentRepository=test::default::file:target/repo
{noformat}
Outcome: Nothing is deployed. The *target/repo* is not created. See output 
attached.

Expected result: Deployment of both modules is performed during submodule's 
deploy phase.

 

I debugged it and think I understand the problem:

1. When the parent module is built, the DeployMojo class is loaded and the
{noformat}
private static final AtomicInteger readyProjectsCounter
{noformat}
is initialized to 0.

2. Then it's bumped to 1 when deploy of "parent" is executed.

3. Then, the second module is built (submodule) and, because it contributes an 
extension, DepoyMojo class is re-loaded (by Guice?) and the
{noformat}
private static final AtomicInteger readyProjectsCounter field{noformat}
is reinitialized to 0.

4. Then it's bumped to 1 when deploy of "submodule" is executed, but since *1 < 
2* the deploy is not performed at all.

 

Not sure how to fix it, anyone?


> Nothing is deployed if deployAtEnd=true  and extension is added in submodule
> 
>
> Key: MDEPLOY-234
> URL: https://issues.apache.org/jira/browse/MDEPLOY-234
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 2.8.2
> Environment: Maven 3.5.3
>Reporter: Piotr Paczynski
>Priority: Major
> Attachments: project.zip, result.txt
>
>
> It seems that when *deploytEnd=true* and one of the submodules in the reactor 
> adds an *extension*, then nothing gets deployed. The last module to build 
> says "Deploying ... at end".
>  
> I'm attaching a minimal project that is affected by the issue. To reproduce, 
> unpack it and issue the following command in the main dir (I've used Maven 
> 3.5.3).
> {noformat}
> mvn deploy -DaltDeploymentRepository=test::default::file:target/repo
> {noformat}
> Outcome: Nothing is deployed. The *target/repo* is not created. See output 
> attached.
> Expected result: Deployment of both modules is performed during submodule's 
> deploy phase.
>  
> I've debugged it and think I understand the problem:
> 1. When the parent module is built, the DeployMojo class is loaded and the
> {noformat}
> private static final AtomicInteger readyProjectsCounter
> {noformat}
> field is initialized to 0.
> 2. Then it's bumped to 1 when deploy of "parent" is executed.
> 3. Then, the second module is built (submodule) and, because it contributes 
> an extension, DepoyMojo class is re-loaded (by Guice?) and the
> {noformat}
> private static final AtomicInteger readyProjectsCounter{noformat}
> field is reinitialized to 0.
> 4. Then it's bumped to 1 when deploy of "submodule" is executed, but since *1 
> < 2* the deploy is not performed at all.
>  
> Not sure how to fix it, anyone?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MDEPLOY-234) Nothing is deployed if deployAtEnd=true and extension is added in submodule

[Piotr Paczynski (JIRA)]

Piotr Paczynski created MDEPLOY-234:
---

 Summary: Nothing is deployed if deployAtEnd=true  and extension is 
added in submodule
 Key: MDEPLOY-234
 URL: https://issues.apache.org/jira/browse/MDEPLOY-234
 Project: Maven Deploy Plugin
  Issue Type: Bug
  Components: deploy:deploy
Affects Versions: 2.8.2
 Environment: Maven 3.5.3
Reporter: Piotr Paczynski
 Attachments: project.zip, result.txt

It seems that when *deploytEnd=true* and one of the submodules in the reactor 
adds an *extension*, then nothing gets deployed. The last module to built says 
"Deploying ... at end".

 

I'm attaching a minimal project that is affected by the issue. To reproduce, 
unpack it and issue the following command in the main dir (I've used Maven 
3.5.3).
{noformat}
mvn deploy -DaltDeploymentRepository=test::default::file:target/repo
{noformat}
Outcome: Nothing is deployed. The *target/repo* is not created. See output 
attached.

Expected result: Deployment of both modules is performed during submodule's 
deploy phase.

 

I debugged it and think I understand the problem:

1. When the parent module is built, the DeployMojo class is loaded and the
{noformat}
private static final AtomicInteger readyProjectsCounter
{noformat}
is initialized to 0.

2. Then it's bumped to 1 when deploy of "parent" is executed.

3. Then, the second module is built (submodule) and, because it contributes an 
extension, DepoyMojo class is re-loaded (by Guice?) and the
{noformat}
private static final AtomicInteger readyProjectsCounter field{noformat}
is reinitialized to 0.

4. Then it's bumped to 1 when deploy of "submodule" is executed, but since *1 < 
2* the deploy is not performed at all.

 

Not sure how to fix it, anyone?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build

[Karl Heinz Marbaise (JIRA)]

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

Karl Heinz Marbaise commented on MNG-6391:
--

Hi, no problem..
I would say the second option to do but without the version in reactor summary 
at all only the supplemental line {{Version: ..}}. In cases where we have an 
aggregator meaning that each module has a different version we should keep it 
and print it in the reactor summary.. [~rfscholte] WDYT ? 

> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version 
> printout but also the last built module.
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib  SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the 
> version printout.
> Also this is not the order I configured the modules in the parent pom but I 
> think this could be something on my side.
> {code:java}
> 
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SCM-882) ScmWagon has no way to work with GIT in binary mode

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433653#comment-16433653
 ] 

ASF GitHub Bot commented on SCM-882:


basinilya opened a new pull request #69: [SCM-882] git checkout in binary mode 
when requested
URL: https://github.com/apache/maven-scm/pull/69
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> ScmWagon has no way to work with GIT in binary mode
> ---
>
> Key: SCM-882
> URL: https://issues.apache.org/jira/browse/SCM-882
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5
>Reporter: Ilya Basin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 1.9.6
>
>
> Msysgit will checkout wagon-scm test-resource with CRLF by default, breaking 
> the test. Need to clone with core.autocrlf=false



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] basinilya opened a new pull request #69: [SCM-882] git checkout in binary mode when requested

[GitBox]

basinilya opened a new pull request #69: [SCM-882] git checkout in binary mode 
when requested
URL: https://github.com/apache/maven-scm/pull/69
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] (SCM-881) ScmWagon has no way to work with SVN in binary mode

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCM-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16433649#comment-16433649
 ] 

ASF GitHub Bot commented on SCM-881:


basinilya opened a new pull request #68: [SCM-881] svn add in binary mode when 
requested
URL: https://github.com/apache/maven-scm/pull/68
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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


> ScmWagon has no way to work with SVN in binary mode
> ---
>
> Key: SCM-881
> URL: https://issues.apache.org/jira/browse/SCM-881
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5
>Reporter: Ilya Basin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 1.9.6
>
>
> In some configurations svn will automatically add the svn:eol-style property 
> to newly added text files. ScmWagon needs to perform the add command without 
> adding automatic properties.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] basinilya opened a new pull request #68: [SCM-881] svn add in binary mode when requested

[GitBox]

basinilya opened a new pull request #68: [SCM-881] svn add in binary mode when 
requested
URL: https://github.com/apache/maven-scm/pull/68
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] (SCM-882) ScmWagon has no way to work with GIT in binary mode

[Ilya Basin (JIRA)]

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

Ilya Basin updated SCM-882:
---
Description: Msysgit will checkout wagon-scm test-resource with CRLF by 
default, breaking the test. Need to clone with core.autocrlf=false  (was: In 
some configurations svn will automatically add the svn:eol-style property to 
newly added text files. ScmWagon needs to perform the add command without 
adding automatic properties.)

> ScmWagon has no way to work with GIT in binary mode
> ---
>
> Key: SCM-882
> URL: https://issues.apache.org/jira/browse/SCM-882
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5
>Reporter: Ilya Basin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 1.9.6
>
>
> Msysgit will checkout wagon-scm test-resource with CRLF by default, breaking 
> the test. Need to clone with core.autocrlf=false



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SCM-882) ScmWagon has no way to work with GIT in binary mode

[Ilya Basin (JIRA)]

Ilya Basin created SCM-882:
--

 Summary: ScmWagon has no way to work with GIT in binary mode
 Key: SCM-882
 URL: https://issues.apache.org/jira/browse/SCM-882
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-cvs
Affects Versions: 1.9.5
Reporter: Ilya Basin
Assignee: Olivier Lamy (*$^¨%`£)
 Fix For: 1.9.6


In some configurations svn will automatically add the svn:eol-style property to 
newly added text files. ScmWagon needs to perform the add command without 
adding automatic properties.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SCM-881) ScmWagon has no way to work with SVN in binary mode

[Ilya Basin (JIRA)]

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

Ilya Basin updated SCM-881:
---
Description: In some configurations svn will automatically add the 
svn:eol-style property to newly added text files. ScmWagon needs to perform the 
add command without adding automatic properties.  (was: By default, CVSNT will 
corrupt jars during `mvn deploy`. Vanilla CVS less likely, but still possible 
due to Keyword substitution. ScmWagon needs to perform checkout and add 
commands with the '-kb' flag (binary).

UPD: In some configurations svn will automatically add the svn:eol-style 
property to newly added text files. ScmWagon needs to perform the add command 
without adding automatic properties.

UPD2: Msysgit will checkout wagon-scm test-resource with CRLF by default, 
breaking the test. Need to clone with core.autocrlf=false)

> ScmWagon has no way to work with SVN in binary mode
> ---
>
> Key: SCM-881
> URL: https://issues.apache.org/jira/browse/SCM-881
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-cvs
>Affects Versions: 1.9.5
>Reporter: Ilya Basin
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 1.9.6
>
>
> In some configurations svn will automatically add the svn:eol-style property 
> to newly added text files. ScmWagon needs to perform the add command without 
> adding automatic properties.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SCM-881) ScmWagon has no way to work with SVN in binary mode

[Ilya Basin (JIRA)]

Ilya Basin created SCM-881:
--

 Summary: ScmWagon has no way to work with SVN in binary mode
 Key: SCM-881
 URL: https://issues.apache.org/jira/browse/SCM-881
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-cvs
Affects Versions: 1.9.5
Reporter: Ilya Basin
Assignee: Olivier Lamy (*$^¨%`£)
 Fix For: 1.9.6


By default, CVSNT will corrupt jars during `mvn deploy`. Vanilla CVS less 
likely, but still possible due to Keyword substitution. ScmWagon needs to 
perform checkout and add commands with the '-kb' flag (binary).

UPD: In some configurations svn will automatically add the svn:eol-style 
property to newly added text files. ScmWagon needs to perform the add command 
without adding automatic properties.

UPD2: Msysgit will checkout wagon-scm test-resource with CRLF by default, 
breaking the test. Need to clone with core.autocrlf=false



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (SUREFIRE-1514) Selecting multiple tests does not work when tests are inside parent class

[Jori (JIRA)]

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

Jori edited comment on SUREFIRE-1514 at 4/11/18 9:10 AM:
-

And another addition: it actually seems to break even single test selection 
when inheritance for tests is involved.

mvn integration-test \-Dit.test=testpackage/SubClass#test1 - works in 2.18.1

mvn integration-test \-Dit.test=testpackage/SubClass#test1 - does not work 
since 2.19.1


was (Author: buumi):
And another addition: it actually seems to break even single test selection 
when inheritance for tests is involved.

mvn integration-test -Dit.test=testpackage/SubClass#test1 - works in 2.18.1

mvn integration-test -Dit.test=testpackage/SubClass#test1 - does not work since 
2.19.1

> Selecting multiple tests does not work when tests are inside parent class
> -
>
> Key: SUREFIRE-1514
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1514
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, TestNG support
>Affects Versions: 2.21.0
>Reporter: Jori
>Priority: Major
> Attachments: maven-project.zip
>
>
> I'm using TestNG to run tests with Maven Failsafe plugin version 2.21.0. I'm 
> trying to follow instructions over at 
> [http://maven.apache.org/surefire/maven-failsafe-plugin/examples/single-test.html]
>  for running multiple tests in a single class:
> mvn -Dit.test=ITCircle#testOne+testTwo verify
> This works fine as long as testOne and testTwo are defined inside the class 
> ITCircle. However, it does not work if ITCircle is a subclass of class 
> ParentClass which holds the test methods. 
>  
> So basically my structure is
> testpackage
>   - ParentClass
>       - public void setup
>       - public void test1
>       - public void test2
>   - SubClass extends ParentClass
>       - public void setup
>  
> mvn \-Dit.test=testpackage.ParentClass verify     - OK (2 tests ran)
> mvn \-Dit.test=testpackage.ParentClass#test1+test2 verify     - OK (2 tests 
> ran)
> mvn \-Dit.test=testpackage.SubClass verify     - OK (2 tests ran)
> mvn \-Dit.test=testpackage.SubClass#test1+test2 verify     - No tests found



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1514) Selecting multiple tests does not work when tests are inside parent class

[Jori (JIRA)]

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

Jori commented on SUREFIRE-1514:


And another addition: it actually seems to break even single test selection 
when inheritance for tests is involved.

mvn integration-test -Dit.test=testpackage/SubClass#test1 - works in 2.18.1

mvn integration-test -Dit.test=testpackage/SubClass#test1 - does not work since 
2.19.1

> Selecting multiple tests does not work when tests are inside parent class
> -
>
> Key: SUREFIRE-1514
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1514
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, TestNG support
>Affects Versions: 2.21.0
>Reporter: Jori
>Priority: Major
> Attachments: maven-project.zip
>
>
> I'm using TestNG to run tests with Maven Failsafe plugin version 2.21.0. I'm 
> trying to follow instructions over at 
> [http://maven.apache.org/surefire/maven-failsafe-plugin/examples/single-test.html]
>  for running multiple tests in a single class:
> mvn -Dit.test=ITCircle#testOne+testTwo verify
> This works fine as long as testOne and testTwo are defined inside the class 
> ITCircle. However, it does not work if ITCircle is a subclass of class 
> ParentClass which holds the test methods. 
>  
> So basically my structure is
> testpackage
>   - ParentClass
>       - public void setup
>       - public void test1
>       - public void test2
>   - SubClass extends ParentClass
>       - public void setup
>  
> mvn \-Dit.test=testpackage.ParentClass verify     - OK (2 tests ran)
> mvn \-Dit.test=testpackage.ParentClass#test1+test2 verify     - OK (2 tests 
> ran)
> mvn \-Dit.test=testpackage.SubClass verify     - OK (2 tests ran)
> mvn \-Dit.test=testpackage.SubClass#test1+test2 verify     - No tests found



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build

[Alexander Griesbaum (JIRA)]

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

Alexander Griesbaum commented on MNG-6391:
--

Hi, sorry for not reading the release notes properly, I created the issue based 
on the 
[example|https://issues.apache.org/jira/browse/MNG-6352?focusedCommentId=16367736=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16367736]
 in MNG-6352.

The current solution is still confusing in my opinion so I am with Robert: a 
new line at the bottom or additional info at the BUILD SUCCESS line.

Info at BUILD SUCCESS:
{code:java}
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
[INFO] parent-lib  SUCCESS [ 0.492 s]
[INFO] commons ... SUCCESS [ 25.444 s]
[INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
[INFO] proxy-config-starter .. SUCCESS [ 7.496 s]
[INFO] 
[INFO] BUILD SUCCESS 4.0.0-SNAPSHOT
[INFO] 
[INFO] Total time: 01:45 min
[INFO] Finished at: 2018-04-11T09:56:21+02:00
[INFO] 
{code}
Info in a separate line (Didn't use "Version Summary" to not being too verbose):
{code:java}
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
[INFO] parent-lib  SUCCESS [ 0.492 s]
[INFO] commons ... SUCCESS [ 25.444 s]
[INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
[INFO] proxy-config-starter .. SUCCESS [ 7.496 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 01:45 min
[INFO] Finished at: 2018-04-11T09:56:21+02:00
[INFO] Version: 4.0.0-SNAPSHOT
[INFO] 
{code}
 

What do you think about it?

> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.5.4
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version 
> printout but also the last built module.
> {code:java}
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO] 
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib  SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the 
> version printout.
> Also this is not the order I configured the modules in the parent pom but I 
> think this could be something on my side.
> {code:java}
> 
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
> 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SUREFIRE-1514) Selecting multiple tests does not work when tests are inside parent class

[Jori (JIRA)]

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

Jori commented on SUREFIRE-1514:


Attached a minimal maven project where above problem occurs. 

> Selecting multiple tests does not work when tests are inside parent class
> -
>
> Key: SUREFIRE-1514
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1514
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, TestNG support
>Affects Versions: 2.21.0
>Reporter: Jori
>Priority: Major
> Attachments: maven-project.zip
>
>
> I'm using TestNG to run tests with Maven Failsafe plugin version 2.21.0. I'm 
> trying to follow instructions over at 
> [http://maven.apache.org/surefire/maven-failsafe-plugin/examples/single-test.html]
>  for running multiple tests in a single class:
> mvn -Dit.test=ITCircle#testOne+testTwo verify
> This works fine as long as testOne and testTwo are defined inside the class 
> ITCircle. However, it does not work if ITCircle is a subclass of class 
> ParentClass which holds the test methods. 
>  
> So basically my structure is
> testpackage
>   - ParentClass
>       - public void setup
>       - public void test1
>       - public void test2
>   - SubClass extends ParentClass
>       - public void setup
>  
> mvn \-Dit.test=testpackage.ParentClass verify     - OK (2 tests ran)
> mvn \-Dit.test=testpackage.ParentClass#test1+test2 verify     - OK (2 tests 
> ran)
> mvn \-Dit.test=testpackage.SubClass verify     - OK (2 tests ran)
> mvn \-Dit.test=testpackage.SubClass#test1+test2 verify     - No tests found



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (SUREFIRE-1514) Selecting multiple tests does not work when tests are inside parent class

[Jori (JIRA)]

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

Jori updated SUREFIRE-1514:
---
Attachment: maven-project.zip

> Selecting multiple tests does not work when tests are inside parent class
> -
>
> Key: SUREFIRE-1514
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1514
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin, TestNG support
>Affects Versions: 2.21.0
>Reporter: Jori
>Priority: Major
> Attachments: maven-project.zip
>
>
> I'm using TestNG to run tests with Maven Failsafe plugin version 2.21.0. I'm 
> trying to follow instructions over at 
> [http://maven.apache.org/surefire/maven-failsafe-plugin/examples/single-test.html]
>  for running multiple tests in a single class:
> mvn -Dit.test=ITCircle#testOne+testTwo verify
> This works fine as long as testOne and testTwo are defined inside the class 
> ITCircle. However, it does not work if ITCircle is a subclass of class 
> ParentClass which holds the test methods. 
>  
> So basically my structure is
> testpackage
>   - ParentClass
>       - public void setup
>       - public void test1
>       - public void test2
>   - SubClass extends ParentClass
>       - public void setup
>  
> mvn \-Dit.test=testpackage.ParentClass verify     - OK (2 tests ran)
> mvn \-Dit.test=testpackage.ParentClass#test1+test2 verify     - OK (2 tests 
> ran)
> mvn \-Dit.test=testpackage.SubClass verify     - OK (2 tests ran)
> mvn \-Dit.test=testpackage.SubClass#test1+test2 verify     - No tests found



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)