[jira] [Comment Edited] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Tibor Digana (JIRA) 

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

Tibor Digana edited comment on SUREFIRE-1222 at 9/20/16 9:24 PM:
-

[~mkouba]
It is not that fast and not without troubles to use other than std/out, e.g. 
file system right now.
It would be easier to use a magic number in the beginning of the stream, e.g. 
0x0F, 0xAC, 0x0B, 0xAD.
Surefire will process lines which start with magic number; otherwise it will be 
printed in console.
The problem should be fixed in Arquillian as well; otherwise the output will 
not be associated with current Thread of the test and would not appear in 
surefire-reports in particular Test-*.txt file report and not in the Maven Site 
test report.


was (Author: tibor17):
[~mkouba]
It is not that fast and not without troubles to use other that std/out, e.g. 
file system right now.
It would be easier to use a magic number in the beginning of the stream, e.g. 
0x0F, 0xAC, 0x0B, 0xAD.
Surefire will process lines which start with magic number; otherwise it will be 
printed in console.
The problem should be fixed in Arquillian as well; otherwise the output will 
not be associated current Thread of the test and would not appear in 
surefire-reports in particular Test-*.txt file report and not in the Maven Site 
test report.

> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1222:


[~mkouba]
It is not that fast and not without troubles to use other that std/out, e.g. 
file system right now.
It would be easier to use a magic number in the beginning of the stream, e.g. 
0x0F, 0xAC, 0x0B, 0xAD.
Surefire will process lines which start with magic number; otherwise it will be 
printed in console.
The problem should be fixed in Arquillian as well; otherwise the output will 
not be associated current Thread of the test and would not appear in 
surefire-reports in particular Test-*.txt file report and not in the Maven Site 
test report.

> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MENFORCER-204) Add new rule: should be able to make sure that project artifact is a Snapshot

2016-09-20 Thread JIRA 

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

Guillaume Boué closed MENFORCER-204.

   Resolution: Fixed
Fix Version/s: 1.4.2

> Add new rule: should be able to make sure that project artifact is a Snapshot
> -
>
> Key: MENFORCER-204
> URL: https://issues.apache.org/jira/browse/MENFORCER-204
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>  Components: Standard Rules
>Affects Versions: 1.4.1
>Reporter: Adrien Lecharpentier
>Assignee: Guillaume Boué
> Fix For: 1.4.2
>
> Attachments: MENFORCER-RequireSnapshotVersion.patch
>
>
> As it is currently possible to validate the current project is a release, we 
> should have to inverse rule: validate the current project is a snapshot.
> The use case: in CI, ensure that the current project is in snapshot version 
> before doing a `mvn deploy`. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MENFORCER-204) Add new rule: should be able to make sure that project artifact is a Snapshot

2016-09-20 Thread JIRA 

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

Guillaume Boué updated MENFORCER-204:
-
Affects Version/s: (was: 2.0)
   1.4.1

> Add new rule: should be able to make sure that project artifact is a Snapshot
> -
>
> Key: MENFORCER-204
> URL: https://issues.apache.org/jira/browse/MENFORCER-204
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>  Components: Standard Rules
>Affects Versions: 1.4.1
>Reporter: Adrien Lecharpentier
>Assignee: Guillaume Boué
> Fix For: 1.4.2
>
> Attachments: MENFORCER-RequireSnapshotVersion.patch
>
>
> As it is currently possible to validate the current project is a release, we 
> should have to inverse rule: validate the current project is a snapshot.
> The use case: in CI, ensure that the current project is in snapshot version 
> before doing a `mvn deploy`. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Tibor Digana (JIRA) 

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

Tibor Digana edited comment on SUREFIRE-1222 at 9/20/16 9:05 PM:
-

[~mkouba]

This code should be okay 
https://github.com/wildfly/wildfly-arquillian/blob/master/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L349

Regarding the code you pointed out
{code}
new ProcessBuilder("echo", "I 29, 2016 2:01:43 
ODP.").redirectOutput(Redirect.INHERIT).start();
{code}
I found the problem. Try to find {{java.lang.ProcessImpl}} in JDK 8 latest 102 
and you will find method:
{code}
start(String cmdarray[],
 java.util.Map environment,
 String dir,
 ProcessBuilder.Redirect[] redirects,
 boolean redirectErrorStream)
{code}

which is called from {{ProcessBuilder.start()}} and you will find this code:
{code}
else if (redirects[1] == Redirect.INHERIT)
stdHandles[1] = fdAccess.getHandle(FileDescriptor.out);
{code}

which calls static context {{FileDescriptor.out}}

This means that the constant references the native {{PrintStream}} which was 
set prior to the stream we set in Surefire after ForkedBooter replaced the 
std/out stream by internal one.


was (Author: tibor17):
[~mkouba]

This code should be okay 
https://github.com/wildfly/wildfly-arquillian/blob/master/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L349

Regarding the code you pointed out
{code}
new ProcessBuilder("echo", "I 29, 2016 2:01:43 
ODP.").redirectOutput(Redirect.INHERIT).start();
{code}
I found the problem. Try to find {{java.lang.ProcessImpl}} in JDK 8 latest 102 
and you will find method:
{code}
start(String cmdarray[],
 java.util.Map environment,
 String dir,
 ProcessBuilder.Redirect[] redirects,
 boolean redirectErrorStream)
{code}

which is called from {{ProcessBuilder.start()}} and you will find this code:
{code}
else if (redirects[1] == Redirect.INHERIT)
stdHandles[1] = fdAccess.getHandle(FileDescriptor.out);
{code}

which calls static context {{FileDescriptor.out}}

This means that the constant references the native {{PrintStream}} which was 
prior to the stream we set in Surefire after ForkedBooter replaced the std/out 
stream by internal one.

> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Tibor Digana (JIRA) 

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

Tibor Digana edited comment on SUREFIRE-1222 at 9/20/16 9:01 PM:
-

[~mkouba]

This code should be okay 
https://github.com/wildfly/wildfly-arquillian/blob/master/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L349

Regarding the code you pointed out
{code}
new ProcessBuilder("echo", "I 29, 2016 2:01:43 
ODP.").redirectOutput(Redirect.INHERIT).start();
{code}
I found the problem. Try to find {{java.lang.ProcessImpl}} in JDK 8 latest 102 
and you will find method:
{code}
start(String cmdarray[],
 java.util.Map environment,
 String dir,
 ProcessBuilder.Redirect[] redirects,
 boolean redirectErrorStream)
{code}

which is called from {{ProcessBuilder.start()}} and you will find this code:
{code}
else if (redirects[1] == Redirect.INHERIT)
stdHandles[1] = fdAccess.getHandle(FileDescriptor.out);
{code}

which calls static context {{FileDescriptor.out}}

This means that the constant references the native {{PrintStream}} which was 
prior to the stream we set in Surefire after ForkedBooter replaced the std/out 
stream by internal one.


was (Author: tibor17):
[~mkouba]

This code should be okay 
https://github.com/wildfly/wildfly-arquillian/blob/master/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L349

Regarding {{new ProcessBuilder("echo", "I 29, 2016 2:01:43 
ODP.").redirectOutput(Redirect.INHERIT).start();}}
I found the problem. Try to find {{java.lang.ProcessImpl}} in JDK 8 latest 102 
and you will find method:
{{start(String cmdarray[],
 java.util.Map environment,
 String dir,
 ProcessBuilder.Redirect[] redirects,
 boolean redirectErrorStream)}}

which is called from {{ProcessBuilder.start()}} and you will find this code:
{{else if (redirects[1] == Redirect.INHERIT)
stdHandles[1] = fdAccess.getHandle(FileDescriptor.out);}}

which calls static context {{FileDescriptor.out}}

This means that the constant references the native {{PrintStream}} which was 
prior to the stream we set in Surefire after ForkedBooter replaced the std/out 
stream by internal one.

> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1222:


[~mkouba]

This code should be okay 
https://github.com/wildfly/wildfly-arquillian/blob/master/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L349

Regarding {{new ProcessBuilder("echo", "I 29, 2016 2:01:43 
ODP.").redirectOutput(Redirect.INHERIT).start();}}
I found the problem. Try to find {{java.lang.ProcessImpl}} in JDK 8 latest 102 
and you will find method:
{{start(String cmdarray[],
 java.util.Map environment,
 String dir,
 ProcessBuilder.Redirect[] redirects,
 boolean redirectErrorStream)}}

which is called from {{ProcessBuilder.start()}} and you will find this code:
{{else if (redirects[1] == Redirect.INHERIT)
stdHandles[1] = fdAccess.getHandle(FileDescriptor.out);}}

which calls static context {{FileDescriptor.out}}

This means that the constant references the native {{PrintStream}} which was 
prior to the stream we set in Surefire after ForkedBooter replaced the std/out 
stream by internal one.

> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MENFORCER-204) Add new rule: should be able to make sure that project artifact is a Snapshot

2016-09-20 Thread Hudson (JIRA) 

[ 
https://issues.apache.org/jira/browse/MENFORCER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507761#comment-15507761
 ] 

Hudson commented on MENFORCER-204:
--

FAILURE: Integrated in Jenkins build maven-enforcer #242 (See 
[https://builds.apache.org/job/maven-enforcer/242/])
[MENFORCER-204] Add new rule: should be able to make sure that project artifact 
is a Snapshot

Adding a RequireSnapshotVersion rule, which is the opposite of the 
RequireReleaseVersion rule. (gboue: 
[http://svn.apache.org/viewvc/?view=rev=1761637])
* (add) 
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSnapshotVersion.java
* (edit) enforcer-rules/src/site/apt/index.apt
* (add) enforcer-rules/src/site/apt/requireSnapshotVersion.apt.vm
* (add) 
enforcer-rules/src/test/java/org/apache/maven/plugins/enforcer/TestRequireSnapshotVersion.java
* (add) maven-enforcer-plugin/src/it/projects/require-snapshot-version_failure
* (add) 
maven-enforcer-plugin/src/it/projects/require-snapshot-version_failure/invoker.properties
* (add) 
maven-enforcer-plugin/src/it/projects/require-snapshot-version_failure/pom.xml
* (add) maven-enforcer-plugin/src/it/projects/require-snapshot-version_success
* (add) 
maven-enforcer-plugin/src/it/projects/require-snapshot-version_success/pom.xml


> Add new rule: should be able to make sure that project artifact is a Snapshot
> -
>
> Key: MENFORCER-204
> URL: https://issues.apache.org/jira/browse/MENFORCER-204
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>  Components: Standard Rules
>Affects Versions: 2.0
>Reporter: Adrien Lecharpentier
>Assignee: Guillaume Boué
> Attachments: MENFORCER-RequireSnapshotVersion.patch
>
>
> As it is currently possible to validate the current project is a release, we 
> should have to inverse rule: validate the current project is a snapshot.
> The use case: in CI, ensure that the current project is in snapshot version 
> before doing a `mvn deploy`. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MENFORCER-204) Add new rule: should be able to make sure that project artifact is a Snapshot

2016-09-20 Thread JIRA 

[ 
https://issues.apache.org/jira/browse/MENFORCER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507743#comment-15507743
 ] 

Guillaume Boué commented on MENFORCER-204:
--

Fixed in 
[r1761637|http://svn.apache.org/viewvc?view=revision=1761637]. Thanks 
for the patch!

> Add new rule: should be able to make sure that project artifact is a Snapshot
> -
>
> Key: MENFORCER-204
> URL: https://issues.apache.org/jira/browse/MENFORCER-204
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>  Components: Standard Rules
>Affects Versions: 2.0
>Reporter: Adrien Lecharpentier
>Assignee: Guillaume Boué
> Attachments: MENFORCER-RequireSnapshotVersion.patch
>
>
> As it is currently possible to validate the current project is a release, we 
> should have to inverse rule: validate the current project is a snapshot.
> The use case: in CI, ensure that the current project is in snapshot version 
> before doing a `mvn deploy`. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MENFORCER-204) Add new rule: should be able to make sure that project artifact is a Snapshot

2016-09-20 Thread JIRA 

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

Guillaume Boué reassigned MENFORCER-204:


Assignee: Guillaume Boué

> Add new rule: should be able to make sure that project artifact is a Snapshot
> -
>
> Key: MENFORCER-204
> URL: https://issues.apache.org/jira/browse/MENFORCER-204
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>  Components: Standard Rules
>Affects Versions: 2.0
>Reporter: Adrien Lecharpentier
>Assignee: Guillaume Boué
> Attachments: MENFORCER-RequireSnapshotVersion.patch
>
>
> As it is currently possible to validate the current project is a release, we 
> should have to inverse rule: validate the current project is a snapshot.
> The use case: in CI, ensure that the current project is in snapshot version 
> before doing a `mvn deploy`. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Martin Kouba (JIRA) 

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

Martin Kouba commented on SUREFIRE-1222:


Ok Tibor, thanks for the link. So you're basically saying that it's not 
possible to start a new process and redirect the output to the standard output 
of the current process (forked surefire process). Instead, we should observe 
the standard output of the new process and {{System.out.write()}} in the parent 
process, like e.g. WildFly Arquillian managed adapter: 
https://github.com/wildfly/wildfly-arquillian/blob/master/container-managed/src/main/java/org/jboss/as/arquillian/container/managed/ManagedDeployableContainer.java#L138

Is there any reason for this limitation? To me both solutions seem legitimate.

By the way, this is a very simple reproducer:
{code:java}
public class SimpleTest {

@Test
public void testDummy() throws IOException {
   new ProcessBuilder("echo", "I 29, 2016 2:01:43 
ODP.").redirectOutput(Redirect.INHERIT).start();
}
}
{code}

> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MWAR-396) Check the existence of the web.xml based on the existence of particular classes

2016-09-20 Thread JIRA 

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

Guillaume Boué closed MWAR-396.
---
Resolution: Fixed

> Check the existence of the web.xml based on the existence of particular 
> classes
> ---
>
> Key: MWAR-396
> URL: https://issues.apache.org/jira/browse/MWAR-396
> Project: Maven WAR Plugin
>  Issue Type: New Feature
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Guillaume Boué
> Fix For: 3.1.0
>
>
> Based on MWAR-262 we have changed the default to {{false}} but the existence 
> of the {{web.xml}} should be checked based on the existence of particular 
> classes? But which?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1222:


I sent you a link where you can see how we redirect streams. We used this
utility yet in Java 5 and 6.

On Tue, Sep 20, 2016 at 2:52 PM, Tibor Digana 



> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1222:


Hi Martin,

Surefire together with Maven is platform for your Tests.
The Redirect class in Arquillian must be implemented in Arquillian project.
I have never seen it.
This means Arquillian should listen to InputStream of child process and
write data to parent process in OutputStream. This would not harm Surefire
then. I saw tests where users override std/out stream as well. If both call
setOut() then both work against each other.

https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/cli/CommandLineUtils.java#L233


On Tue, Sep 20, 2016 at 11:58 AM, Martin Kouba (JIRA) 



> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines

2016-09-20 Thread Martin Kouba (JIRA) 

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

Martin Kouba commented on SUREFIRE-1222:


Hi Tibor,
Well, the tests do not call {{System.setOut()}} but the [Arquillian 
adapter|https://github.com/arquillian/arquillian-container-se] creates a new 
process and then redirects its output (i.e. calls 
{{java.lang.ProcessBuilder.redirectOutput(Redirect)}}) to the output of the JVM 
which runs the test. 

In any case, I think that 
[ForkClient.consumeLine()|http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven.surefire/maven-surefire-common/2.18.1/org/apache/maven/plugin/surefire/booterclient/output/ForkClient.java#85]
 should expect similar lines (containing comma and code) and ignore them. E.g. 
the code/operationId could be prefixed with some uncommon prefix... e.g. 
{{:::I}} instead of {{I}} for BOOTERCODE_SYSPROPS.

> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>
> This month the [Weld 
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite 
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default 
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of 
> range: -1
>   at java.lang.String.substring(String.java:1911)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
>   at 
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception 
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29 
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}} 
> operation.
> I think the protocol should be robust enough to avoid similar collisions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1228) rerunFailingTestsCount + TestNG + @DataProvider = failed tests pass

2016-09-20 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1228:


[~juherr]
The rerun feature does not exist in TestNG provider.
If somebody has such ambition, she/he can implement it in TestNG provider since 
of certain TestNG version.

> rerunFailingTestsCount + TestNG + @DataProvider = failed tests pass
> ---
>
> Key: SUREFIRE-1228
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1228
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: TestNG support
>Affects Versions: 2.19.1
>Reporter: Cam Morris
>Assignee: Tibor Digana
> Attachments: TestRandomFail.java, pom.xml
>
>
> Surefire confuses tests run with a data-provider with rerun tests so only one 
> of the data-provided tests need to pass.
> Steps to reproduce:
> # Create a testNG test with a data provider that passes with some of the data 
> and fails with others
> {code:title=TestNG example|language=java}
>   @Test(dataProvider = "succeed")
>   public void fail(boolean succeed) {
> if (!succeed) {
>   Assert.fail("nope");
> }
>   }
>   @DataProvider(name="succeed")
>   public Object[][] arrayIndex() {
> return new Object[][]{ {true}, {false}};
>   }
> {code}
> # Configure surefire to rerun failed tests
> {code:title=pom.xml example|language=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
> cam.test
> testng-retry
> 1.0-SNAPSHOT
> 
> 
> org.testng
> testng
> 6.9.10
> test
> 
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
> 
>   1
> 
> 
> 
> 
> 
> {code}
> - *Expected results*:  "Tests run: 2, Failures: 1..."  The tests should not 
> pass.
> - *Actual results*: "Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, 
> Flakes: 1"  The rerun confuses test runs with different data for retry 
> attempts.  Just one of the data provider tests needs to succeed for the test 
> to be deemed a success.
> {code}mvn test
> ...
> ---
>  T E S T S
> ---
> Running TestRandomFail
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.267 sec <<< 
> FAILURE! - in TestRandomFail
> fail(TestRandomFail)  Time elapsed: 0.007 sec  <<< FAILURE!
> java.lang.AssertionError: nope
> at TestRandomFail.fail(TestRandomFail.java:14)
> Results :
> Flaked tests: 
> TestRandomFail.fail(TestRandomFail)
>   Run 1: PASS
>   Run 2: TestRandomFail.fail:14 nope
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Flakes: 1
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 2.251 s
> [INFO] Finished at: 2016-02-10T07:39:21-07:00
> [INFO] Final Memory: 9M/244M
> [INFO] 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1228) rerunFailingTestsCount + TestNG + @DataProvider = failed tests pass

2016-09-20 Thread Julien Herr (JIRA) 

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

Julien Herr commented on SUREFIRE-1228:
---

I don't know how rerunFailingTestsCount is implemented in the testng provider 
(maybe it is not) but testng provides a similar feature out of the box named 
RetryAnaylzer. 
A workaround could be to replace rerunFailingTestsCount usage by it,  
rerunFailingTestsCount could use it. 
It is possible to rerun only a part of data provider tests but the feature was 
broken for a while and I fixed it few days/weeks ago (should be available in 
the latest version) 

> rerunFailingTestsCount + TestNG + @DataProvider = failed tests pass
> ---
>
> Key: SUREFIRE-1228
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1228
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: TestNG support
>Affects Versions: 2.19.1
>Reporter: Cam Morris
>Assignee: Tibor Digana
> Attachments: TestRandomFail.java, pom.xml
>
>
> Surefire confuses tests run with a data-provider with rerun tests so only one 
> of the data-provided tests need to pass.
> Steps to reproduce:
> # Create a testNG test with a data provider that passes with some of the data 
> and fails with others
> {code:title=TestNG example|language=java}
>   @Test(dataProvider = "succeed")
>   public void fail(boolean succeed) {
> if (!succeed) {
>   Assert.fail("nope");
> }
>   }
>   @DataProvider(name="succeed")
>   public Object[][] arrayIndex() {
> return new Object[][]{ {true}, {false}};
>   }
> {code}
> # Configure surefire to rerun failed tests
> {code:title=pom.xml example|language=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
> cam.test
> testng-retry
> 1.0-SNAPSHOT
> 
> 
> org.testng
> testng
> 6.9.10
> test
> 
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
> 
>   1
> 
> 
> 
> 
> 
> {code}
> - *Expected results*:  "Tests run: 2, Failures: 1..."  The tests should not 
> pass.
> - *Actual results*: "Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, 
> Flakes: 1"  The rerun confuses test runs with different data for retry 
> attempts.  Just one of the data provider tests needs to succeed for the test 
> to be deemed a success.
> {code}mvn test
> ...
> ---
>  T E S T S
> ---
> Running TestRandomFail
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.267 sec <<< 
> FAILURE! - in TestRandomFail
> fail(TestRandomFail)  Time elapsed: 0.007 sec  <<< FAILURE!
> java.lang.AssertionError: nope
> at TestRandomFail.fail(TestRandomFail.java:14)
> Results :
> Flaked tests: 
> TestRandomFail.fail(TestRandomFail)
>   Run 1: PASS
>   Run 2: TestRandomFail.fail:14 nope
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Flakes: 1
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 2.251 s
> [INFO] Finished at: 2016-02-10T07:39:21-07:00
> [INFO] Final Memory: 9M/244M
> [INFO] 
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)