[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Dan Tran (JIRA)


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

Dan Tran edited comment on SUREFIRE-1546 at 2/2/19 6:53 AM:


what is the final verdict? 

what is the format of adding display name to std-out:   displayName= ? and 
as the first line of each test case ( test method) stdout?




was (Author: dantran):
what is the final verdict? 

what is the format of adding display name to std-out:   displayName= ?



> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Dan Tran (JIRA)


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

Dan Tran commented on SUREFIRE-1546:


what is the final verdict? 

what is the format of adding display name to std-out:   displayName= ?



> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana commented on SUREFIRE-1546:


> I strongly suggest to not alter the XML format used by Ant/Surefire in an 
> incompatible manner.

Dan is not aiming for a new format. As I have understood him, he wants to keep 
the current XSD but only alter values (real or display).
I guess these users want to use User Scenario of BDD instead of real class name 
like it is in Spock and every class is testing another scenario.

Personally I would prefer having new attributes and Jenkins plugins upgrades 
but users do not require that right now however it can be added as late as 
possible.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana edited comment on SUREFIRE-1546 at 2/1/19 10:44 PM:
-

[~sor]
{quote}
I strongly suggest to not alter the XML format used by Ant/Surefire in an 
incompatible manner.
{quote}
Dan is not aiming for a new format. As I have understood him, he wants to keep 
the current XSD format but only alter values (real or display).
I guess these users want to use User Scenario of BDD instead of real class name 
like it is in Spock and every class is testing another scenario.

Personally I would prefer having new attributes and Jenkins plugins upgrades 
but users do not require that right now however it can be added as late as 
possible.

As we agreed, we will add display name in {{std-out}}.


was (Author: tibor17):
[~sor]
{quote}
I strongly suggest to not alter the XML format used by Ant/Surefire in an 
incompatible manner.
{quote}
Dan is not aiming for a new format. As I have understood him, he wants to keep 
the current XSD format but only alter values (real or display).
I guess these users want to use User Scenario of BDD instead of real class name 
like it is in Spock and every class is testing another scenario.

Personally I would prefer having new attributes and Jenkins plugins upgrades 
but users do not require that right now however it can be added as late as 
possible.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana edited comment on SUREFIRE-1546 at 2/1/19 10:43 PM:
-

[~sor]
{quote}
I strongly suggest to not alter the XML format used by Ant/Surefire in an 
incompatible manner.
{quote}
Dan is not aiming for a new format. As I have understood him, he wants to keep 
the current XSD format but only alter values (real or display).
I guess these users want to use User Scenario of BDD instead of real class name 
like it is in Spock and every class is testing another scenario.

Personally I would prefer having new attributes and Jenkins plugins upgrades 
but users do not require that right now however it can be added as late as 
possible.


was (Author: tibor17):
> I strongly suggest to not alter the XML format used by Ant/Surefire in an 
> incompatible manner.

Dan is not aiming for a new format. As I have understood him, he wants to keep 
the current XSD but only alter values (real or display).
I guess these users want to use User Scenario of BDD instead of real class name 
like it is in Spock and every class is testing another scenario.

Personally I would prefer having new attributes and Jenkins plugins upgrades 
but users do not require that right now however it can be added as late as 
possible.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[GitHub] eolivelli commented on issue #43: [MENFORCER-314] - Warn if EnforcerRuleException has no message

2019-02-01 Thread GitBox
eolivelli commented on issue #43: [MENFORCER-314] - Warn if 
EnforcerRuleException has no message
URL: https://github.com/apache/maven-enforcer/pull/43#issuecomment-459886481
 
 
   @famod great work.
   
   Will commit 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


[GitHub] eolivelli closed pull request #48: [MENFORCER-324] - Shouldn't we use System.lineSeparator() instead?

2019-02-01 Thread GitBox
eolivelli closed pull request #48: [MENFORCER-324] - Shouldn't we use 
System.lineSeparator() instead?
URL: https://github.com/apache/maven-enforcer/pull/48
 
 
   


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] (MNG-6069) Migrate to non deprecated parts of Commons CLI

2019-02-01 Thread Hudson (JIRA)


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

Hudson commented on MNG-6069:
-

Build failed in Jenkins: Maven TLP » maven » master #159

See https://builds.apache.org/job/maven-box/job/maven/job/master/159/

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



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


[jira] [Updated] (MNG-6069) Migrate to non deprecated parts of Commons CLI

2019-02-01 Thread Sylwester Lachiewicz (JIRA)


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

Sylwester Lachiewicz updated MNG-6069:
--
Fix Version/s: (was: 3.6.1)
   3.x / Backlog

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.x / Backlog
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



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


[jira] [Reopened] (MNG-6069) Migrate to non deprecated parts of Commons CLI

2019-02-01 Thread Sylwester Lachiewicz (JIRA)


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

Sylwester Lachiewicz reopened MNG-6069:
---
  Assignee: (was: Sylwester Lachiewicz)

> Migrate to non deprecated parts of Commons CLI
> --
>
> Key: MNG-6069
> URL: https://issues.apache.org/jira/browse/MNG-6069
> Project: Maven
>  Issue Type: Improvement
>  Components: Embedding
>Affects Versions: 3.3.9, 3.5.0-alpha-1, 3.5.0-beta-1, 3.5.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> At the moment all parts of {{OptionBuilder...}} are marked deprecated in 
> {{CLIManager}}. They should be migrated to:
> {code:java}
> Option.builder( HELP ).longOpt( "help" ).desc( "Display help information" 
> ).build()
> {code}



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


[jira] [Commented] (JXR-143) New goals jxr-no-fork and test-jxr-no-fork which will not invoke generate-*-sources

2019-02-01 Thread Matt Nelson (JIRA)


[ 
https://issues.apache.org/jira/browse/JXR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758514#comment-16758514
 ] 

Matt Nelson commented on JXR-143:
-

[~rfscholte] [~khmarbaise] Can you advise on the next steps I need to do in 
order to make progress on this issue?

> New goals jxr-no-fork and test-jxr-no-fork which will not invoke 
> generate-*-sources
> ---
>
> Key: JXR-143
> URL: https://issues.apache.org/jira/browse/JXR-143
> Project: Maven JXR
>  Issue Type: Improvement
>  Components: jxr
>Reporter: Matt Nelson
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Identical root issues as MJAVADOC-369
> Add new goals which do not fork the build when those phases have already 
> executed.



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


[jira] [Created] (SUREFIRE-1633) [JUnit5 follow-up #1343] JUnit Jupiter @Nested tests do not run when selecting enclosing class with Surefire

2019-02-01 Thread Christian Stein (JIRA)
Christian Stein created SUREFIRE-1633:
-

 Summary: [JUnit5 follow-up #1343] JUnit Jupiter @Nested tests do 
not run when selecting enclosing class with Surefire
 Key: SUREFIRE-1633
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1633
 Project: Maven Surefire
  Issue Type: Bug
  Components: JUnit 5.x support
Reporter: Christian Stein


https://github.com/junit-team/junit5/issues/1343



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


[GitHub] famod commented on issue #43: [MENFORCER-314] - Warn if EnforcerRuleException has no message

2019-02-01 Thread GitBox
famod commented on issue #43: [MENFORCER-314] - Warn if EnforcerRuleException 
has no message
URL: https://github.com/apache/maven-enforcer/pull/43#issuecomment-459788214
 
 
   I jumped ahead and extended `TestEnforceMojo`. IMHO this should be 
sufficient for such a small change.
   
   Please note that I won't be able to put much more effort into this entire 
issue as I am busy elsewhere.
   
   PS: Yes, I did see that there is a custom `MockEnforcerRule` but I saw no 
real sense in extending this with more logic as mockito is just way more 
flexible at such tasks (and you need to write less code).


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-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Christian Stein (JIRA)


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

Christian Stein commented on SUREFIRE-1546:
---

Having a config parameter that allows display name in said places of the 
generated XML and TXT files ... calls for troubles. But it might be a 
short-term solution.

 

A long-term solution is to be designed and implemented here: 
[https://github.com/ota4j-team/opentest4j/issues/9] – you're very welcome to 
join the effort.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Christian Stein (JIRA)


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

Christian Stein edited comment on SUREFIRE-1546 at 2/1/19 4:30 PM:
---

Having a config parameter that allows display name in said places of the 
generated XML and TXT files ... calls for troubles.

But it might be a short-term -solution- band-aid.

 

A long-term solution is to be designed and implemented here: 
[https://github.com/ota4j-team/opentest4j/issues/9] – you're very welcome to 
join the effort.


was (Author: sor):
Having a config parameter that allows display name in said places of the 
generated XML and TXT files ... calls for troubles. But it might be a 
short-term solution.

 

A long-term solution is to be designed and implemented here: 
[https://github.com/ota4j-team/opentest4j/issues/9] – you're very welcome to 
join the effort.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Dan Tran (JIRA)


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

Dan Tran commented on SUREFIRE-1546:


correction, we are not parsing the content of display name but for reporting 
purpose only. And also agree, we must not break the compatibility

so using an additional surefire config should be perfect for us

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Christian Stein (JIRA)


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

Christian Stein commented on SUREFIRE-1546:
---

Display names are not intended and are not even able to be used reliably as 
suggested by [~dantran] – see this 
[TestIdentifier.html#getDisplayName()|https://junit.org/junit5/docs/current/api/org/junit/platform/launcher/TestIdentifier.html#getDisplayName()]
 documentation:
{quote}A _display name_ is a human-readable name for a test or container that 
is typically used for test reporting in IDEs and build tools. Display names may 
contain spaces, special characters, and emoji, and the format may be customized 
by 
[{{TestEngines}}|https://junit.org/junit5/docs/current/api/org/junit/platform/engine/TestEngine.html]
 or potentially by end users as well. Consequently, display names should never 
be parsed; rather, they should be used for display purposes only.
{quote}
Using display name in place like

{{}}

will lead to problems. Users may provide a single shard display name for all 
containers and tests... or down-stream tools might rely on having "real" Java 
class names and method names here.
{quote}We plan to print display name in std-out and std-err.
{quote}
This is the option chosen by the JUnit Team. It attaches the arbitrary display 
name to the report entry of the originating source. So, down-stream tools can 
extract from here. Find the sources of our soon released XML writer at GitHub, 
and the lines related to new attributes (like unique-id and displayName) here: 
https://github.com/junit-team/junit5/blob/master/junit-platform-reporting/src/main/java/org/junit/platform/reporting/legacy/xml/XmlReportWriter.java#L279-L280

I strongly suggest to *not* alter the XML format used by Ant/Surefire in an 
incompatible manner.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana commented on SUREFIRE-1546:


[~thuybdo]
[~dantran]
ok, so, it looks like you do not want to wait for a new XSD updates and Jenkins 
plugin, and we should alter the behavior in config parameters.
Is this right?

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Thuy Do (JIRA)


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

Thuy Do commented on SUREFIRE-1546:
---

I second Dan's request.  Having a DisplayName is crucial to my team's test 
automation.  We use the DisplayName to generate report.  Please either keep the 
implementation or provide an option to use it.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana commented on SUREFIRE-1546:


We have two options.

First we would add an extension as a new config parameter with a complex object 
where all these alternatives can be switched on.

Second, add two more XML attributes (displayedName, displayedSourceName). But 
here we already placed XSD version {{3.0}}.
It would be nice to align version of XSD with version of plugin but it is not 
mandatory for me. In this case xUnit plugin has to be announced again.

> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Comment Edited] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Dan Tran (JIRA)


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

Dan Tran edited comment on SUREFIRE-1546 at 2/1/19 2:59 PM:


For reporting purpose.   We parse TEST-*.xml under target/surefire-report to 
render the report at Micro Focus quality center.  

So having displayName to replace the actual testcase's name and classname are 
so crucial for us.

{code:java}

{code}

We are also using 
https://github.com/BogdanLivadariu/bootstraped-multi-test-results-report to 
post report to jenkins as well 

please please keep the implementation, or provide an option to activate it



was (Author: dantran):
For reporting purpose.   We parse TEST-*.xml under target/surefire-report to 
render the report at Micro Focus quality center.  

So having displayName to replace the actual testcase's name and classname are 
so crucial for us.

{code:java}

{code}

It works


> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Commented] (SUREFIRE-1546) JUnit 5 runner does not honor JUnit 5 display names

2019-02-01 Thread Dan Tran (JIRA)


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

Dan Tran commented on SUREFIRE-1546:


For reporting purpose.   We parse TEST-*.xml under target/surefire-report to 
render the report at Micro Focus quality center.  

So having displayName to replace the actual testcase's name and classname are 
so crucial for us.

{code:java}

{code}

It works


> JUnit 5 runner does not honor JUnit 5 display names
> ---
>
> Key: SUREFIRE-1546
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1546
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support
>Affects Versions: 2.22.0
>Reporter: Romain Manni-Bucau
>Assignee: Tibor Digana
>Priority: Major
>  Labels: junit5
> Fix For: 3.0.0-M4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> JUnit 5 runner should respect the test @DisplayName instead of displaying the 
> classname if any is defined. Seems last release doesn't support that feature 
> of JUnit 5 making the console output and reports not the expected ones.
>  
> Origin: https://github.com/junit-team/junit5/issues/990



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


[jira] [Updated] (MSHARED-799) Change "Created-By" manifest entry value to be reproducible

2019-02-01 Thread Michael Osipov (JIRA)


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

Michael Osipov updated MSHARED-799:
---
Summary: Change "Created-By" manifest entry value to be reproducible  (was: 
Change "Created-By" manifest entry value to reproducible one)

> Change "Created-By" manifest entry value to be reproducible
> ---
>
> Key: MSHARED-799
> URL: https://issues.apache.org/jira/browse/MSHARED-799
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> as seen during work on MSHARED-787, the current value for {{Created-By}} 
> entry is {{Maven $\{maven.version}}} which is not reproducible
> it would be better to have {{Maven Archiver $\{ma.version\}}} value by default
> and an easy to use API for plugins that use the component to override the 
> value with a more precise value like {{Maven XXX Plugin $\{version\}}}



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


[jira] [Commented] (SUREFIRE-1623) TempWmicBatchFile.bat is left in project dirs after surefire tests are run

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana commented on SUREFIRE-1623:


What provider you use? Junit4 or JUnit47 or another?
The most trivial project is enough to have to reproduce this issue?

> TempWmicBatchFile.bat is left in project dirs after surefire tests are run
> --
>
> Key: SUREFIRE-1623
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1623
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Chris Graham
>Priority: Blocker
>
> WINDOWS ONLY:
> When the WMIC command it run to obtain the process start time, the current 
> implementation leaves behind a batch file, TempWmicBatchFile.bat, which is 
> zero bytes long.
> This file needs to be removed post execution.
> Leaving it behind will interfere with the release plugin as a scm status call 
> will fail with files needing to be added. Simply ignoring the file is a very 
> sloppy approach.



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


[GitHub] dmitri-gb opened a new pull request #15: [MSHADE-223] - Endless processing with promoteTransitiveDependencies

2019-02-01 Thread GitBox
dmitri-gb opened a new pull request #15: [MSHADE-223] - Endless processing with 
promoteTransitiveDependencies
URL: https://github.com/apache/maven-shade-plugin/pull/15
 
 
   Fix the endless processing that was caused by not checking the classifier of 
the dependencies when adding excludes.
   
   I opted for just comparing the results of the `getId` method, as it already 
contains all the necessary info (groupId + artifactId + type + classifier). The 
previous check `dep.getType() == null` seems unnecessary, as the type is 
generally never `null`.
   
   I also added an integration test that reproduces the issue. It includes an 
`invoker.properties` file that sets `invoker.timeoutInSeconds=60`, because 
without the fix the issue manifests as a non-terminating build.
   
   - [x] I hereby declare this contribution to be licenced under the [Apache 
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)


This is an automated message from the Apache Git Service.
To respond to the message, please log on 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] (MSHARED-799) Change "Created-By" manifest entry value to reproducible one

2019-02-01 Thread Michael Osipov (JIRA)


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

Michael Osipov updated MSHARED-799:
---
Summary: Change "Created-By" manifest entry value to reproducible one  
(was: change "Created-By" manifest entry value to reproducible one)

> Change "Created-By" manifest entry value to reproducible one
> 
>
> Key: MSHARED-799
> URL: https://issues.apache.org/jira/browse/MSHARED-799
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> as seen during work on MSHARED-787, the current value for {{Created-By}} 
> entry is {{Maven $\{maven.version}}} which is not reproducible
> it would be better to have {{Maven Archiver $\{ma.version\}}} value by default
> and an easy to use API for plugins that use the component to override the 
> value with a more precise value like {{Maven XXX Plugin $\{version\}}}



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


[jira] [Closed] (MSHARED-787) Add optional buildEnvironment information to the manifest

2019-02-01 Thread Michael Osipov (JIRA)


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

Michael Osipov closed MSHARED-787.
--
Resolution: Fixed

Fixed with 
[93f5ba12836b7b5bb0f9de27ede8bcbd6e46551a|https://gitbox.apache.org/repos/asf?p=maven-archiver.git;a=commit;h=93f5ba12836b7b5bb0f9de27ede8bcbd6e46551a].

> Add optional buildEnvironment information to the manifest
> -
>
> Key: MSHARED-787
> URL: https://issues.apache.org/jira/browse/MSHARED-787
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> People are demanding to have more control about the build information 
> (MSHARED-362). We should add the following to control this: 
> {{ which is by default disabled. It will 
> contain the folling properties (akin to {{mvn- v}}):
> {noformat}
> Build-Tool: ${maven.build.version:-Apache Maven}
> Build-Jdk: ${java.version} (${java.vendor})
> Build-Os:  ${os.name} (${os.version}; (${os.arch})
> {noformat}



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


[jira] [Assigned] (MSHARED-799) change "Created-By" manifest entry value to reproducible one

2019-02-01 Thread Michael Osipov (JIRA)


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

Michael Osipov reassigned MSHARED-799:
--

Assignee: Michael Osipov

> change "Created-By" manifest entry value to reproducible one
> 
>
> Key: MSHARED-799
> URL: https://issues.apache.org/jira/browse/MSHARED-799
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> as seen during work on MSHARED-787, the current value for {{Created-By}} 
> entry is {{Maven $\{maven.version}}} which is not reproducible
> it would be better to have {{Maven Archiver $\{ma.version\}}} value by default
> and an easy to use API for plugins that use the component to override the 
> value with a more precise value like {{Maven XXX Plugin $\{version\}}}



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


[jira] [Commented] (MSHARED-799) change "Created-By" manifest entry value to reproducible one

2019-02-01 Thread Michael Osipov (JIRA)


[ 
https://issues.apache.org/jira/browse/MSHARED-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758259#comment-16758259
 ] 

Michael Osipov commented on MSHARED-799:


I'd move the easy-to-use API to separate ticket. What should happen to the 
created by entry if {{addDefaultEntries}} is set to {{false}}. Shall we 
completely mute the Plexus Archiver default? I think yes because PA is an 
implementation detail. Appropriate methods are included in PA now.

> change "Created-By" manifest entry value to reproducible one
> 
>
> Key: MSHARED-799
> URL: https://issues.apache.org/jira/browse/MSHARED-799
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Hervé Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>
> as seen during work on MSHARED-787, the current value for {{Created-By}} 
> entry is {{Maven $\{maven.version}}} which is not reproducible
> it would be better to have {{Maven Archiver $\{ma.version\}}} value by default
> and an easy to use API for plugins that use the component to override the 
> value with a more precise value like {{Maven XXX Plugin $\{version\}}}



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


[jira] [Commented] (MSHARED-787) Add optional buildEnvironment information to the manifest

2019-02-01 Thread Hudson (JIRA)


[ 
https://issues.apache.org/jira/browse/MSHARED-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758260#comment-16758260
 ] 

Hudson commented on MSHARED-787:


Build succeeded in Jenkins: Maven TLP » maven-archiver » master #54

See https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/54/

> Add optional buildEnvironment information to the manifest
> -
>
> Key: MSHARED-787
> URL: https://issues.apache.org/jira/browse/MSHARED-787
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.3.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-archiver-3.4.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> People are demanding to have more control about the build information 
> (MSHARED-362). We should add the following to control this: 
> {{ which is by default disabled. It will 
> contain the folling properties (akin to {{mvn- v}}):
> {noformat}
> Build-Tool: ${maven.build.version:-Apache Maven}
> Build-Jdk: ${java.version} (${java.vendor})
> Build-Os:  ${os.name} (${os.version}; (${os.arch})
> {noformat}



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


[jira] [Closed] (MNG-6582) Maven report wrong jdk vendor

2019-02-01 Thread Michael Osipov (JIRA)


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

Michael Osipov closed MNG-6582.
---
   Resolution: Not A Problem
Fix Version/s: (was: wontfix-candidate)

> Maven report wrong jdk vendor 
> --
>
> Key: MNG-6582
> URL: https://issues.apache.org/jira/browse/MNG-6582
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.5.4, 3.6.0
>Reporter: Patrick Barry
>Priority: Minor
>
> I am using OpenJDK and when I perform mvn -version, it says Oracle is the 
> vendor.
> {noformat}
> mvn -version 
>  Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
> 2018-06-17T14:33:14-04:00) Maven home: /usr/local/Cellar/maven/3.5.4/libexec 
> Java version: 11.0.2, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home Default 
> locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: 
> "10.13.6", arch: "x86_64", family: "mac"
>  {noformat}
> If you were to print the java version straight from the java install path:
>  {noformat}
> /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java 
> -version 
>  openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment 18.9 (build 
> 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
>  {noformat}
> I updated to the latest install of Maven, and the problem exists there as 
> well.  Testing done on a Mac.



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


[jira] [Comment Edited] (SUREFIRE-1623) TempWmicBatchFile.bat is left in project dirs after surefire tests are run

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana edited comment on SUREFIRE-1623 at 2/1/19 8:28 AM:


[~ChrisGWarp]
Regarding driver, the {{WMIC}} is run without path to {{WMIC}}. It should be in 
PATH.
The path might be {{%SystemRoot%\System32\Wbem\wmic.exe}} used directly in 
command (not the CWD) if exist; otherwise {{CMD /A /X /C wmic process where 
(ProcessId=123) get CreationDate}}.
What you mean by {{driver for the change}} ? What change? The {{CreationDate}} ?


was (Author: tibor17):
[~ChrisGWarp]
Regarding driver, the {{WMIC}} is run without path to {{WMIC}}. It should be in 
PATH.
The path might be {{%SystemRoot%\\System32\Wbem\wmic.exe}} used directly in 
command (not the CWD) if exist; otherwise {{CMD /A /X /C wmic process where 
(ProcessId=123) get CreationDate}}.
What you mean by {{driver for the change}} ? What change? The {{CreationDate}} ?

> TempWmicBatchFile.bat is left in project dirs after surefire tests are run
> --
>
> Key: SUREFIRE-1623
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1623
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Chris Graham
>Priority: Blocker
>
> WINDOWS ONLY:
> When the WMIC command it run to obtain the process start time, the current 
> implementation leaves behind a batch file, TempWmicBatchFile.bat, which is 
> zero bytes long.
> This file needs to be removed post execution.
> Leaving it behind will interfere with the release plugin as a scm status call 
> will fail with files needing to be added. Simply ignoring the file is a very 
> sloppy approach.



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


[jira] [Comment Edited] (SUREFIRE-1623) TempWmicBatchFile.bat is left in project dirs after surefire tests are run

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana edited comment on SUREFIRE-1623 at 2/1/19 8:28 AM:


[~ChrisGWarp]
Regarding driver, the {{WMIC}} is run without path to {{WMIC}}. It should be in 
PATH.
The path might be {{%SystemRoot%\\System32\Wbem\wmic.exe}} used directly in 
command (not the CWD) if exist; otherwise {{CMD /A /X /C wmic process where 
(ProcessId=123) get CreationDate}}.
What you mean by {{driver for the change}} ? What change? The {{CreationDate}} ?


was (Author: tibor17):
[~ChrisGWarp]
Regarding driver, the {{WMIC}} is run without path to {{WMIC}}. It should be in 
PATH.
The path might be {{%SystemRoot%\\System32\Wbem\wmic.exe}} used directly in 
command (not the CWD) if exist; otherwise {{CMD /A /X /C wmic process where 
(ProcessId=123) get CreationDate}}.
What you mean by {{driver for the change }}? What change? The {{CreationDate}}?

> TempWmicBatchFile.bat is left in project dirs after surefire tests are run
> --
>
> Key: SUREFIRE-1623
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1623
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Chris Graham
>Priority: Blocker
>
> WINDOWS ONLY:
> When the WMIC command it run to obtain the process start time, the current 
> implementation leaves behind a batch file, TempWmicBatchFile.bat, which is 
> zero bytes long.
> This file needs to be removed post execution.
> Leaving it behind will interfere with the release plugin as a scm status call 
> will fail with files needing to be added. Simply ignoring the file is a very 
> sloppy approach.



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


[jira] [Commented] (SUREFIRE-1623) TempWmicBatchFile.bat is left in project dirs after surefire tests are run

2019-02-01 Thread Tibor Digana (JIRA)


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

Tibor Digana commented on SUREFIRE-1623:


[~ChrisGWarp]
Regarding driver, the {{WMIC}} is run without path to {{WMIC}}. It should be in 
PATH.
The path might be {{%SystemRoot%\\System32\Wbem\wmic.exe}} used directly in 
command (not the CWD) if exist; otherwise {{CMD /A /X /C wmic process where 
(ProcessId=123) get CreationDate}}.
What you mean by {{driver for the change }}? What change? The {{CreationDate}}?

> TempWmicBatchFile.bat is left in project dirs after surefire tests are run
> --
>
> Key: SUREFIRE-1623
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1623
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Chris Graham
>Priority: Blocker
>
> WINDOWS ONLY:
> When the WMIC command it run to obtain the process start time, the current 
> implementation leaves behind a batch file, TempWmicBatchFile.bat, which is 
> zero bytes long.
> This file needs to be removed post execution.
> Leaving it behind will interfere with the release plugin as a scm status call 
> will fail with files needing to be added. Simply ignoring the file is a very 
> sloppy approach.



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