[jira] [Commented] (MNG-5576) Allow continuous delivery friendly versions

2016-08-29 Thread Karl Heinz Marbaise (JIRA) 

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

Karl Heinz Marbaise commented on MNG-5576:
--

You wrote from {{resolved project's}} where should it be defined ? There must 
be at least one location where it's need to be defined. So if you take a multi 
module build you can define it once in the root of that multi module build. In 
the child modules it might be implemented to accept {{project.version}}.  So 
currently the {{revision}}, {{sha1}} and {{changelist}} is at the moment 
defined which means they are allowed to prevent emitting of warnings during the 
build and using special properties which can be defined from command line of 
from {{.mvn/maven.confg}} file...but this concepts can of course being improved 
so you just omit the {{project.version}} completely. My assumption about the 
implementation is simply to use properties instead doing much more complicated 
things..(For this you might better ask Jason van Zyl).

> Allow continuous delivery friendly versions
> ---
>
> Key: MNG-5576
> URL: https://issues.apache.org/jira/browse/MNG-5576
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.1.1
>Reporter: Jason van Zyl
> Fix For: 3.2.1
>
>
> Currently warnings will be emitted when there are expressions in versions, a 
> few exceptions should be deemed valid to make continuous delivery easier. The 
> use case is to allow easy versioning of an entire multi-module build that can 
> take a version from an external source like SCM. These are the types of 
> exceptions that will be allowed:
> 1.0.0.$\{changelist}
> 1.0.0.$\{revision}
> 1.0.0.$\{sha1}
> When a whole build is versioned like this we can avoid churning the POMs in 
> the SCM which makes it a lot easier to see the actual changes in the project. 
> Not a complete solution for continuous delivery but is a step in the right 
> direction and doesn't interfere with currently behavior as it is currently 
> allowed, just warned against.



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

[jira] [Comment Edited] (MNG-5576) Allow continuous delivery friendly versions

2016-08-29 Thread Vincent Massol (JIRA) 

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

Vincent Massol edited comment on MNG-5576 at 8/29/16 4:17 PM:
--

{quote}
furthermore if you use project.version from where should it be taken?
{quote}

>From the resolved project's version.

What I don't understand and my comment is for this issue, not another one 
(otherwise I'd have created it elsewhere...), is why the restriction on 
{{revision}}, {{sha1}} and {{changelist}} property names. 

Re the list I'm not subscribed to the list (not been for years now) and I don't 
intend to join it. This was just a one-off question related to a specific jira 
issue.


was (Author: vmassol):
{quote}
furthermore if you use ${project.version} from where should it be taken?
{quote}

>From the resolved project's version.

What I don't understand and my comment is for this issue, not another one 
(otherwise I'd have created it elsewhere...), is why the restriction on 
{{revision}}, {{sha1}} and {{changelist}} property names. 

Re the list I'm not subscribed to the list (not been for years now) and I don't 
intend to join it. This was just a one-off question related to a specific jira 
issue.

> Allow continuous delivery friendly versions
> ---
>
> Key: MNG-5576
> URL: https://issues.apache.org/jira/browse/MNG-5576
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.1.1
>Reporter: Jason van Zyl
> Fix For: 3.2.1
>
>
> Currently warnings will be emitted when there are expressions in versions, a 
> few exceptions should be deemed valid to make continuous delivery easier. The 
> use case is to allow easy versioning of an entire multi-module build that can 
> take a version from an external source like SCM. These are the types of 
> exceptions that will be allowed:
> 1.0.0.$\{changelist}
> 1.0.0.$\{revision}
> 1.0.0.$\{sha1}
> When a whole build is versioned like this we can avoid churning the POMs in 
> the SCM which makes it a lot easier to see the actual changes in the project. 
> Not a complete solution for continuous delivery but is a step in the right 
> direction and doesn't interfere with currently behavior as it is currently 
> allowed, just warned against.



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

[jira] [Commented] (MNG-5576) Allow continuous delivery friendly versions

2016-08-29 Thread Vincent Massol (JIRA) 

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

Vincent Massol commented on MNG-5576:
-

{quote}
furthermore if you use ${project.version} from where should it be taken?
{quote}

>From the resolved project's version.

What I don't understand and my comment is for this issue, not another one 
(otherwise I'd have created it elsewhere...), is why the restriction on 
{{revision}}, {{sha1}} and {{changelist}} property names. 

Re the list I'm not subscribed to the list (not been for years now) and I don't 
intend to join it. This was just a one-off question related to a specific jira 
issue.

> Allow continuous delivery friendly versions
> ---
>
> Key: MNG-5576
> URL: https://issues.apache.org/jira/browse/MNG-5576
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.1.1
>Reporter: Jason van Zyl
> Fix For: 3.2.1
>
>
> Currently warnings will be emitted when there are expressions in versions, a 
> few exceptions should be deemed valid to make continuous delivery easier. The 
> use case is to allow easy versioning of an entire multi-module build that can 
> take a version from an external source like SCM. These are the types of 
> exceptions that will be allowed:
> 1.0.0.$\{changelist}
> 1.0.0.$\{revision}
> 1.0.0.$\{sha1}
> When a whole build is versioned like this we can avoid churning the POMs in 
> the SCM which makes it a lot easier to see the actual changes in the project. 
> Not a complete solution for continuous delivery but is a step in the right 
> direction and doesn't interfere with currently behavior as it is currently 
> allowed, just warned against.



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

[jira] [Commented] (MINSTALL-126) localRepositoryPath for install like for install-file

2016-08-29 Thread Jesse Glick (JIRA) 

[ 
https://issues.apache.org/jira/browse/MINSTALL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446301#comment-15446301
 ] 

Jesse Glick commented on MINSTALL-126:
--

In my case there is no simple list of coördinates I could purge in that 
fashion, as I work on numerous projects from time to time, and other people do 
releases in some of them.

> localRepositoryPath for install like for install-file
> -
>
> Key: MINSTALL-126
> URL: https://issues.apache.org/jira/browse/MINSTALL-126
> Project: Maven Install Plugin
>  Issue Type: Improvement
>Reporter: Michael Vorburger
>
> I believe there are real world use cases where to have a localRepositoryPath 
> available for maven-install-plugin's install goal like it currently is for 
> the install-file goal would be useful.
> http://blog2.vorburger.ch/2016/06/maven-install-into-additional.html is a 
> Blog post I wrote with some background about why this would be useful.



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

[jira] [Commented] (MNG-5576) Allow continuous delivery friendly versions

2016-08-29 Thread Karl Heinz Marbaise (JIRA) 

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

Karl Heinz Marbaise commented on MNG-5576:
--

First why using an old issue instead of creating a new one and not discuss this 
on the dev list?...furthermore if you use {{$\{project.version\}}} from where 
should it be taken? Apart from that you can use a {{revision}}, {{sha1}} or 
{{changelist}} etc. in the parent and you can use {{-Drevision=x}} on 
command line etc. I would suggest to remove you comment and create either a new 
issue (feature request) or better start a discussion on the dev list?

> Allow continuous delivery friendly versions
> ---
>
> Key: MNG-5576
> URL: https://issues.apache.org/jira/browse/MNG-5576
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.1.1
>Reporter: Jason van Zyl
> Fix For: 3.2.1
>
>
> Currently warnings will be emitted when there are expressions in versions, a 
> few exceptions should be deemed valid to make continuous delivery easier. The 
> use case is to allow easy versioning of an entire multi-module build that can 
> take a version from an external source like SCM. These are the types of 
> exceptions that will be allowed:
> 1.0.0.$\{changelist}
> 1.0.0.$\{revision}
> 1.0.0.$\{sha1}
> When a whole build is versioned like this we can avoid churning the POMs in 
> the SCM which makes it a lot easier to see the actual changes in the project. 
> Not a complete solution for continuous delivery but is a step in the right 
> direction and doesn't interfere with currently behavior as it is currently 
> allowed, just warned against.



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

[jira] [Commented] (MPLUGIN-313) Error injecting JavaAnnotationsMojoDescriptorExtractor

2016-08-29 Thread Paul Benedict (JIRA) 

[ 
https://issues.apache.org/jira/browse/MPLUGIN-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446275#comment-15446275
 ] 

Paul Benedict commented on MPLUGIN-313:
---

I went to a new machine and retried my project. The POM error gone away so I 
believe your theory of a corrupt local repository is correct. However, I am not 
out of the woods yet because something else is stopping me (but that is 
unrelated to this issue)...

Of curious note:
My use of {{mvn --update-plugins}} never solved the corrupted metadata issue. I 
ran that several times on my other machine hoping the metadata would be 
re-downloaded, but it did not. Don't you think it should? If a file is invalid, 
an update attempt should (in my expectation) see if it can be fixed by 
retrieving a new copy -- or at least retrieving a new copy of the hash as a 
smoke test. Perhaps I should move this ticket to project MNG because it sounds 
like Maven could do more to solve this problem automatically. WDYT?

> Error injecting JavaAnnotationsMojoDescriptorExtractor
> --
>
> Key: MPLUGIN-313
> URL: https://issues.apache.org/jira/browse/MPLUGIN-313
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: API
>Affects Versions: 3.5
>Reporter: Paul Benedict
>Priority: Blocker
>
> In the latest 3.5 snapshot, an exception prevents the building of a Mojo. I 
> tagged this as a "blocker" because I cannot find a workaround.
> Messages and stack trace:
> {code}
> [WARNING] The POM for 
> org.apache.maven.plugin-tools:maven-plugin-tools-annotations:jar:3.5-20160826.210808-25
>  is invalid, transitive dependencies (if any) will not be available, enable 
> debug logging for more details
> [INFO] java-javadoc mojo extractor found 0 mojo descriptor.
> [WARNING] Error injecting: 
> org.apache.maven.tools.plugin.extractor.annotations.JavaAnnotationsMojoDescriptorExtractor
> java.lang.NoClassDefFoundError: 
> org/codehaus/plexus/archiver/manager/NoSuchArchiverException
>   at java.lang.Class.getDeclaredConstructors0(Native Method)
>   at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
>   at java.lang.Class.getDeclaredConstructors(Class.java:2020)
>   at 
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
>   at 
> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
>   at 
> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:657)
>   at 
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:875)
>   at 
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:798)
>   at 
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:281)
>   at 
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:213)
>   at 
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:998)
>   at 
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1031)
>   at 
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:994)
>   at 
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
>   at 
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
>   at 
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
>   at 
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
>   at 
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
>   at 
> org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
>   at 
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
>   at 
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
>   at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
>   at 
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
>   at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
>   at 
>

[jira] [Comment Edited] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds

2016-08-29 Thread Michael Musgrove (JIRA) 

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

Michael Musgrove edited comment on SUREFIRE-1265 at 8/29/16 2:36 PM:
-

OK agreed. I am still seeing the issue with the java.corba module which is 
where I first hit this issue. The attached reproducer (it replaces the previous 
one and adds an extra test which imports one of the classes in the java.corba 
module) shows the problem:

bq. mvn clean test -DreuseForks=false -DchildDelegation=false
 fails with NoClassDefFoundError: java/sql/SQLException
bq. mvn clean test -DreuseForks=false -DchildDelegation=true
 fails with NoClassDefFoundError: org/omg/CORBA/BAD_INV_ORDER
bq. mvn clean test -DreuseForks=true -DchildDelegation=
 both tests pass



was (Author: mmusgrov):
OK agreed. I am still seeing the issue with the java.corba module which is 
where I first hit this issue. The attached reproducer shows the problem:

bq. mvn clean test -DreuseForks=false -DchildDelegation=false
 fails with NoClassDefFoundError: java/sql/SQLException
bq. mvn clean test -DreuseForks=false -DchildDelegation=true
 fails with NoClassDefFoundError: org/omg/CORBA/BAD_INV_ORDER
bq. mvn clean test -DreuseForks=true -DchildDelegation=
 both tests pass


> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
>  Labels: jigsaw
> Attachments: j9test.tar
>
>
> When I run any surefire test (with reuseForks=false) that uses java.sql 
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on 
> project maven-surefire-plugin-example: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: 
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException 
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122 
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw 
> team addressed: 
> d20279be77d9  8154189 Deprivilege java.sql and java.sql.rowset module



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

[jira] [Updated] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds

2016-08-29 Thread Michael Musgrove (JIRA) 

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

Michael Musgrove updated SUREFIRE-1265:
---
Attachment: j9test.tar

OK agreed. I am still seeing the issue with the java.corba module which is 
where I first hit this issue. The attached reproducer shows the problem:

bq. mvn clean test -DreuseForks=false -DchildDelegation=false
 fails with NoClassDefFoundError: java/sql/SQLException
bq. mvn clean test -DreuseForks=false -DchildDelegation=true
 fails with NoClassDefFoundError: org/omg/CORBA/BAD_INV_ORDER
bq. mvn clean test -DreuseForks=true -DchildDelegation=
 both tests pass


> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
>  Labels: jigsaw
> Attachments: j9test.tar
>
>
> When I run any surefire test (with reuseForks=false) that uses java.sql 
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on 
> project maven-surefire-plugin-example: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: 
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException 
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122 
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw 
> team addressed: 
> d20279be77d9  8154189 Deprivilege java.sql and java.sql.rowset module



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

[jira] [Updated] (SUREFIRE-1265) reuseForks=false fails on jdk-9-ea builds

2016-08-29 Thread Michael Musgrove (JIRA) 

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

Michael Musgrove updated SUREFIRE-1265:
---
Attachment: (was: j9test.tar)

> reuseForks=false fails on jdk-9-ea builds
> -
>
> Key: SUREFIRE-1265
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1265
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Musgrove
>Assignee: Tibor Digana
>  Labels: jigsaw
>
> When I run any surefire test (with reuseForks=false) that uses java.sql 
> classes on recent jdk-9 ea builds it fails with:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on 
> project maven-surefire-plugin-example: Execution default-test of goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test failed: 
> java.lang.NoClassDefFoundError: java/sql/SQLException: java.sql.SQLException 
> -> [Help 1]
> If I run it with reuseForks=true it works fine.
> This problem was introduced in jdk build 9-ea+122 
> (http://download.java.net/java/jdk9/changes/jdk-9+122.html) when the jigsaw 
> team addressed: 
> d20279be77d9  8154189 Deprivilege java.sql and java.sql.rowset module



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

[jira] [Commented] (MCHANGES-373) It is not possible to use "filter" parameter

2016-08-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/MCHANGES-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445639#comment-15445639
 ] 

ASF GitHub Bot commented on MCHANGES-373:
-

GitHub user mpet opened a pull request:

https://github.com/apache/maven-plugins/pull/91

MCHANGES-373



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mpet/maven-plugins MCHANGES-373

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/91.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #91


commit 699dd3bf3649c150913a0dd1eda25966bc6f6f1c
Author: mike 
Date:   2016-08-29T11:39:24Z

MCHANGES-373




> It is not possible to use "filter" parameter
> 
>
> Key: MCHANGES-373
> URL: https://issues.apache.org/jira/browse/MCHANGES-373
> Project: Maven Changes Plugin
>  Issue Type: Bug
>  Components: jira
>Affects Versions: 2.12
>Reporter: Angel Cervera Claudio
>Priority: Critical
>
> "filter" parameter is always ignored.
> The reason is that this parameter is not set:
> RestJiraDownloader.java line 145:
> new JqlQueryBuilder( log ).urlEncode( false ).project( jiraProject 
> ).fixVersion( getFixFor() ).fixVersionIds( resolvedFixVersionIds ).statusIds( 
> resolvedStatusIds ).priorityIds( resolvedPriorityIds ).resolutionIds( 
> resolvedResolutionIds ).components( resolvedComponentIds ).typeIds( 
> resolvedTypeIds ).sortColumnNames( sortColumnNames ).build();
> 



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

[jira] [Commented] (MPLUGIN-313) Error injecting JavaAnnotationsMojoDescriptorExtractor

2016-08-29 Thread Robert Scholte (JIRA) 

[ 
https://issues.apache.org/jira/browse/MPLUGIN-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445607#comment-15445607
 ] 

Robert Scholte commented on MPLUGIN-313:


I think there's something else going on, like a corrupt local repository. 
Please provide a small example and the output of {{mvn -v}}

> Error injecting JavaAnnotationsMojoDescriptorExtractor
> --
>
> Key: MPLUGIN-313
> URL: https://issues.apache.org/jira/browse/MPLUGIN-313
> Project: Maven Plugin Tools
>  Issue Type: Bug
>  Components: API
>Affects Versions: 3.5
>Reporter: Paul Benedict
>Priority: Blocker
>
> In the latest 3.5 snapshot, an exception prevents the building of a Mojo. I 
> tagged this as a "blocker" because I cannot find a workaround.
> Messages and stack trace:
> {code}
> [WARNING] The POM for 
> org.apache.maven.plugin-tools:maven-plugin-tools-annotations:jar:3.5-20160826.210808-25
>  is invalid, transitive dependencies (if any) will not be available, enable 
> debug logging for more details
> [INFO] java-javadoc mojo extractor found 0 mojo descriptor.
> [WARNING] Error injecting: 
> org.apache.maven.tools.plugin.extractor.annotations.JavaAnnotationsMojoDescriptorExtractor
> java.lang.NoClassDefFoundError: 
> org/codehaus/plexus/archiver/manager/NoSuchArchiverException
>   at java.lang.Class.getDeclaredConstructors0(Native Method)
>   at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
>   at java.lang.Class.getDeclaredConstructors(Class.java:2020)
>   at 
> com.google.inject.spi.InjectionPoint.forConstructorOf(InjectionPoint.java:245)
>   at 
> com.google.inject.internal.ConstructorBindingImpl.create(ConstructorBindingImpl.java:99)
>   at 
> com.google.inject.internal.InjectorImpl.createUninitializedBinding(InjectorImpl.java:657)
>   at 
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl.java:875)
>   at 
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(InjectorImpl.java:798)
>   at 
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.java:281)
>   at 
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:213)
>   at 
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java:998)
>   at 
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1031)
>   at 
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:994)
>   at 
> com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
>   at 
> org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
>   at 
> com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
>   at 
> com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
>   at 
> com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:115)
>   at 
> org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:126)
>   at 
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
>   at 
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
>   at 
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
>   at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
>   at 
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
>   at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
>   at 
> com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:36)
>   at 
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
>   at 
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
>   at 
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
>   at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
>   at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:81)
>   at 
> org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
>   at java.util.AbstractMap.get(AbstractMap.java:187)
>   at 
>

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1255:


I think it's the same issue we have in SUREFIRE-1268, pls have a look.
This is what we do with the STDOUT in Surefire:
original stream = setOut() <= ,  "\n".
Correct me if I am wrong. I think all should be working fine if
Surefire calls {{System.setOut()}} first and then you with stdout
wrapper.
How can we force the JVM to print native messaged in STDOUT to a file
to see what's really going on with the native stream?



-- 
Cheers
Tibor


> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Maximilian Michels (JIRA) 

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

Maximilian Michels commented on SUREFIRE-1255:
--

I suppose I didn't catch all the stdout replacements. If I find time, I can try 
again.

Thanks for looking into the problem!

> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Maximilian Michels (JIRA) 

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

Maximilian Michels commented on SUREFIRE-1255:
--

I assumed STDIN would actually give an EOF if the underlying process died but I 
guess that's not always the case.

> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Commented] (SUREFIRE-1268) With JUnit listener, redirectTestOutputToFile is ignored

2016-08-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1268:


... and this configuration with {{RollingRandomAccessFile}} has the same 
symptoms of the bug?
Please tell me the artifact name including version of log4jXXX you use and I 
will ask 
[~garydgregory] if the Log4J calls {{System.setOut()}} without wrapping the 
stream origin.

> With JUnit listener, redirectTestOutputToFile is ignored
> 
>
> Key: SUREFIRE-1268
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1268
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: Linux
>Reporter: Francesco Chicchiriccò
>Assignee: Tibor Digana
>
> When specifying, according to [this 
> doc|http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_Custom_Listeners_and_Reporters],
>  a JUnit listener, the test output is sent to STDOUT, even though 
> {{redirectTestOutputToFile}} is set to {{true}}.
> This happens with log4j2 configuration for {{SYSTEM_OUT}}, regular 
> {{System.out.println}} works fine.
> With no {{properties}} element, {{redirectTestOutputToFile}} is honored.



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

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1255:


The replacement with the wrapper is the only way. I should think about
why this does not work for you and I should try by myself.



-- 
Cheers
Tibor


> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Assigned] (SUREFIRE-1268) With JUnit listener, redirectTestOutputToFile is ignored

2016-08-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana reassigned SUREFIRE-1268:
--

Assignee: Tibor Digana

> With JUnit listener, redirectTestOutputToFile is ignored
> 
>
> Key: SUREFIRE-1268
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1268
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: Linux
>Reporter: Francesco Chicchiriccò
>Assignee: Tibor Digana
>
> When specifying, according to [this 
> doc|http://maven.apache.org/surefire/maven-surefire-plugin/examples/junit.html#Using_Custom_Listeners_and_Reporters],
>  a JUnit listener, the test output is sent to STDOUT, even though 
> {{redirectTestOutputToFile}} is set to {{true}}.
> This happens with log4j2 configuration for {{SYSTEM_OUT}}, regular 
> {{System.out.println}} works fine.
> With no {{properties}} element, {{redirectTestOutputToFile}} is honored.



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

[jira] [Comment Edited] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Maximilian Michels (JIRA) 

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

Maximilian Michels edited comment on SUREFIRE-1255 at 8/29/16 8:58 AM:
---

I was suspecting that and I remember replacing stdout and stderr with a wrapper 
that would print to both the original stream and the redirection stream. That 
one also failed the tests. Could there be another reason? You're right, I might 
have forgotten some stdout replacements.

Unfortunately, we can't use {{forkCount=0}} for our integration tests because 
we want to have clean environment every time we execute a new test class.




was (Author: mxm):
I was suspecting the say and I remember replacing stdout and stderr with a 
wrapper that would print to both the original stream and the redirection 
stream. That one also failed the tests. Could there be another reason?

Unfortunately, we can't use {{forkCount=0}} for our integration tests because 
we want to have clean environment every time we execute a new test class.



> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Maximilian Michels (JIRA) 

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

Maximilian Michels commented on SUREFIRE-1255:
--

I was suspecting the say and I remember replacing stdout and stderr with a 
wrapper that would print to both the original stream and the redirection 
stream. That one also failed the tests. Could there be another reason?

Unfortunately, we can't use {{forkCount=0}} for our integration tests because 
we want to have clean environment every time we execute a new test class.



> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1255:


If the main process is killed after specified timeout, STDIN would not
know and the CI would not be able  to perform {{mvn clean}}.



-- 
Cheers
Tibor


> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Maximilian Michels (JIRA) 

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

Maximilian Michels commented on SUREFIRE-1255:
--

If the child process is listening on STDIN for commands of the parent process, 
doesn't it get an EOF when the parent process exits? Why do you need to send 
NOP commands?



> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1255:


The main difference between Versions {{2.18.1}} and {{2.19}} is ping feature 
and sending NOP command to the forked process which was not possible in 
{{2.18.1}} and earlier. The point is that the forked VM kills itself as soon as 
two commands NOP are not received because this would mean the main Maven 
process was shutdown via {{CTRL-C}} or killed.
And so if you override the communication channel in forked JVM, the VM 
activates this mechanism and kills itself which means the main process is 
waiting for command {{BOOTERCODE_NEXT_TEST}} which will never arive and there 
the main process hangs.

> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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

[jira] [Comment Edited] (MNG-5576) Allow continuous delivery friendly versions

2016-08-29 Thread Vincent Massol (JIRA) 

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

Vincent Massol edited comment on MNG-5576 at 8/29/16 7:18 AM:
--

Hi. Why not support any property in {{/}} elements in POM or 
if that's not possible, why not support {{${project.version}}}?

I'd like to be able to to write:

{code}
...
  
org.xwiki.platform
xwiki-platform-activeinstalls
${project.version}
  
...
{code}

And in the top level POM have:

{code}
...
  1.0-SNAPSHOT
...
{code}

Thanks


was (Author: vmassol):
Hi. Why not support any property in / elements in POM or if 
that's not possible, why not support ${project.version}?

I'd like to be able to to write:

{code}
...
  
org.xwiki.platform
xwiki-platform-activeinstalls
${project.version}
  
...
{code}

And in the top level POM have:

{code}
...
  1.0-SNAPSHOT
...
{code}

Thanks

> Allow continuous delivery friendly versions
> ---
>
> Key: MNG-5576
> URL: https://issues.apache.org/jira/browse/MNG-5576
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.1.1
>Reporter: Jason van Zyl
> Fix For: 3.2.1
>
>
> Currently warnings will be emitted when there are expressions in versions, a 
> few exceptions should be deemed valid to make continuous delivery easier. The 
> use case is to allow easy versioning of an entire multi-module build that can 
> take a version from an external source like SCM. These are the types of 
> exceptions that will be allowed:
> 1.0.0.$\{changelist}
> 1.0.0.$\{revision}
> 1.0.0.$\{sha1}
> When a whole build is versioned like this we can avoid churning the POMs in 
> the SCM which makes it a lot easier to see the actual changes in the project. 
> Not a complete solution for continuous delivery but is a step in the right 
> direction and doesn't interfere with currently behavior as it is currently 
> allowed, just warned against.



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

[jira] [Commented] (MNG-5576) Allow continuous delivery friendly versions

2016-08-29 Thread Vincent Massol (JIRA) 

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

Vincent Massol commented on MNG-5576:
-

Hi. Why not support any property in / elements in POM or if 
that's not possible, why not support ${project.version}?

I'd like to be able to to write:

{code}
...
  
org.xwiki.platform
xwiki-platform-activeinstalls
${project.version}
  
...
{code}

And in the top level POM have:

{code}
...
  1.0-SNAPSHOT
...
{code}

Thanks

> Allow continuous delivery friendly versions
> ---
>
> Key: MNG-5576
> URL: https://issues.apache.org/jira/browse/MNG-5576
> Project: Maven
>  Issue Type: Improvement
>Affects Versions: 3.1.1
>Reporter: Jason van Zyl
> Fix For: 3.2.1
>
>
> Currently warnings will be emitted when there are expressions in versions, a 
> few exceptions should be deemed valid to make continuous delivery easier. The 
> use case is to allow easy versioning of an entire multi-module build that can 
> take a version from an external source like SCM. These are the types of 
> exceptions that will be allowed:
> 1.0.0.$\{changelist}
> 1.0.0.$\{revision}
> 1.0.0.$\{sha1}
> When a whole build is versioned like this we can avoid churning the POMs in 
> the SCM which makes it a lot easier to see the actual changes in the project. 
> Not a complete solution for continuous delivery but is a step in the right 
> direction and doesn't interfere with currently behavior as it is currently 
> allowed, just warned against.



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

[jira] [Commented] (SUREFIRE-1255) Surefire 2.19.1 hangs before starting test execution

2016-08-29 Thread Tibor Digana (JIRA) 

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

Tibor Digana commented on SUREFIRE-1255:


I think I know why it happens.
The code calls {{System.setOut()}} and {{System.setErr()}}.
This is exactly what we use as well.
It is our bi-directional communication between plugin process and forked 
process. If you really need to stay with the code, you may want to use 
in-plugin process testing which means you simply configure {{forkCount=0}} and 
use {{parallel}} instead of forking.
I should maybe update our documentation about this problem and I should maybe 
force the tests fail via SecurityManager as soon as such calls are made; 
otherwise without stack trace it would not be easy to find who is calling 
{{System.setOut()}}. We have similar issue like this where the tests hang if 
Log4J is used for STD/OUT.

> Surefire 2.19.1 hangs before starting test execution
> 
>
> Key: SUREFIRE-1255
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1255
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.19.1
>Reporter: Maximilian Michels
>Assignee: Tibor Digana
>Priority: Critical
>
> Seeing the same error as SUREFIRE-1193 in Apache Flink builds after upgrading 
> from 2.18.1 to 2.19.1. No errors, builds just gets stuck at the beginning of 
> tests with no log output from the test itself, e.g. 
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/137118454/log.txt
> After a couple of minutes Surefire reports 
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test 
> (integration-tests) on project flink-scala-shell_2.10: ExecutionException The 
> forked VM terminated without properly saying goodbye. VM crash or System.exit 
> called?
> [ERROR] Command was /bin/sh -c cd 
> /home/travis/build/mxm/flink/flink-scala-shell/target && 
> /usr/lib/jvm/java-8-oracle/jre/bin/java -Xms256m -Xmx800m -Dmvn.forkNumber=1 
> -XX:-UseGCOverheadLimit -jar 
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefirebooter372520169616801479.jar
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire8229439069544382018tmp
>  
> /home/travis/build/mxm/flink/flink-scala-shell/target/surefire/surefire_26373613144387982724tmp
> [ERROR] -> [Help 1]
> {noformat}
> We have a a couple of test classes that suffer from this problem. Tests don't 
> read from STDIN or replace it. Switching back to 2.18.1 eliminates the 
> problem (Ran over 100 builds). It seems to be a race condition because it 
> only occurs every once in a while, i.e. ~ 2 out of 10 builds on Travis. I 
> haven't been able to reproduce the problem locally.
> More logs: 
> https://s3.amazonaws.com/flink-logs-us/travis-artifacts/mxm/flink/849/849.1.tar.gz



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