Surefire Forked JVM starts hanging on FreeBSD

I have created Jira for well known issue https://issues.apache.org/jira/browse/SUREFIRE-1339 The branches surefire/experimental-2.19.2 and maven-shared-utils-0.9.x explore the bug as a communication issue between two JVMs. Maven process handles an event which means forked JVM acquires test class

Re: Passing a system property already defined on CLI to Failsafe Plugin

You can think of PR in github and alter the behavior on configuration level. Maybe we should think of extension in the configuration parameter performed in the same way used in maven-shade-plugin: implementation=my/Class. This implementation would compute effective system properties, merge them,

Re: Passing a system property already defined on CLI to Failsafe Plugin

"maven.repo.local" is used automatically by maven-verifier to set-up the local repository (see https://github.com/apache/maven-shared/blob/trunk/maven-verifier/src/main/java/org/apache/maven/it/Verifier.java#L1732), so it would have been nice to refer directly to it in the

Re: Passing a system property already defined on CLI to Failsafe Plugin

>>Perhaps the user properties should be set first, and then any systemPropertyVariables? I don't think so. User's properties should be finally preferable however I understand that you do not want to have so hard restriction. The solution would be the idiom I mentioned before where

Re: Passing a system property already defined on CLI to Failsafe Plugin

I just tried it, and it's the same issue. Digging further into the code, it looks like the issue is here https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireProperties.java#L140-L159. User properties are set

Re: Passing a system property already defined on CLI to Failsafe Plugin

Have you tried this? ${project.build.directory}/it-repo ... maven-failsafe-plugin: ${maven.repo.local} On Sun, Feb 26, 2017 at 10:01 PM, Guillaume Boué wrote: > Hi, > > When a system property is passed on the CLI by the user, with > -Dprop=value, it seems

Re: Passing a system property already defined on CLI to Failsafe Plugin

probably because we have never tested with -Dmaven.repo.local=... Personally I use to *mvn install -P run-its -s /path/to/settings.xml* which IntelliJ IDEA does natively. On Sun, Feb 26, 2017 at 10:02 PM, Guillaume Boué-2 [via Maven] < ml-node+s40175n5900361...@n5.nabble.com> wrote: > Hi, > >

Passing a system property already defined on CLI to Failsafe Plugin

Hi, When a system property is passed on the CLI by the user, with -Dprop=value, it seems that it is always preferred in the ITs of the Failsafe Plugin, even when setting it to a different value in the configuration. I think this is due to SUREFIRE-121, but is there a good way around that? I

[GitHub] maven-surefire issue #144: Resource leaks.

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/144 But most of these changes are not related to communication between JVMs. I spoke with Michael-O and we know the root cause. The problem is that the JVM does not receive data via

[GitHub] maven-surefire pull request #144: Resource leaks.

Github user stephenc commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/144#discussion_r103110391 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/ConsoleOutputFileReporter.java --- @@ -69,8 +69,8 @@ public

[GitHub] maven-surefire pull request #144: Resource leaks.

Github user ChristianSchulte commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/144#discussion_r103110250 --- Diff: surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java --- @@ -236,13 +236,17 @@ private static void

[GitHub] maven-surefire pull request #144: Resource leaks.

Github user ChristianSchulte commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/144#discussion_r103110034 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/ConsoleOutputFileReporter.java --- @@ -69,8 +69,8 @@

[GitHub] maven-surefire pull request #144: Resource leaks.

Github user ChristianSchulte commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/144#discussion_r103109929 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java --- @@ -240,6 +240,10 @@

[GitHub] maven-surefire pull request #144: Resource leaks.

Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/144#discussion_r103107177 --- Diff: surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java --- @@ -236,13 +236,17 @@ private static void exit( int

[GitHub] maven-surefire pull request #144: Resource leaks.

Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/144#discussion_r103107040 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/ConsoleOutputFileReporter.java --- @@ -69,8 +69,8 @@ public

[GitHub] maven-surefire pull request #144: Resource leaks.

Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/144#discussion_r103106957 --- Diff: surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java --- @@ -236,13 +236,17 @@ private static void exit( int

[GitHub] maven-surefire pull request #144: Resource leaks.

Github user Tibor17 commented on a diff in the pull request: https://github.com/apache/maven-surefire/pull/144#discussion_r103106853 --- Diff: maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java --- @@ -240,6 +240,10 @@ public

Re: svn commit: r1784413 - in /maven/plugins/trunk/maven-javadoc-plugin/src/it: MJAVADOC-181/ MJAVADOC-181/application/src/main/java/app/ MJAVADOC-181/library/module-a/src/main/java/aaa/ MJAVADOC-181/

great work! thank you Hervé Le dimanche 26 février 2017, 00:55:46 CET gb...@apache.org a écrit : > Author: gboue > Date: Sun Feb 26 00:55:45 2017 > New Revision: 1784413 > > URL: http://svn.apache.org/viewvc?rev=1784413=rev > Log: > Fixing the ITs so that the project can be built with JDK 8 >

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

@Stephen The problem is no problem. Sorry my bad during private method refactoring in an IT. No issue. On Sun, Feb 26, 2017 at 2:03 PM, stephenconnolly [via Maven] < ml-node+s40175n5900267...@n5.nabble.com> wrote: > We can investigate... > > Could also be an invoker issue as we are just

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

We can investigate... Could also be an invoker issue as we are just effectively passing through the parsed options On Sun 26 Feb 2017 at 12:59, Tibor Digana wrote: > @Stephen > I have an issue with system properties. Could it be caused by the Builder? > There is no

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

@Stephen I have an issue with system properties. Could it be caused by the Builder? There is no space between *-Dtest=* and profile *-P* clean -Dsurefire.version=2.19.2-SNAPSHOT *-Dtest=-P* surefire-junit47 test Since this is JUnit 4.8 test only, this happened after I removed TestNG useless

Re: Jenkins Build IT's / JenkinsFile

Hi, Ok added a comment to an existing issue: https://issues.apache.org/jira/browse/INFRA-13580 Thanks. Kind regards Karl Heinz Marbaise On 26/02/17 13:22, Hervé BOUTEMY wrote: yes, INFRA has to be informed if you find issues remember that Windows nodes don't have same JDK or Maven

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

Am 02/26/17 um 13:03 schrieb Stephen Connolly: > Even if we had a -1 as long as I have the binding votes *as release > manager* it would be my call whether to release or not. > > Now *personally* I much rather release with consensus, but any committer > can step up to be release manager for any

Re: Jenkins Build IT's / JenkinsFile

Yeah -3 has issues. I was going to investigate later today or on Monday. Likely it's easy to fix with some fun on my behalf (benefits of being a Jenkins core developer;-) ) When we can move to pipeline model definition life will be easier but I need Andrew Bayer to add some syntax support for

Re: Jenkins Build IT's / JenkinsFile

yes, INFRA has to be informed if you find issues remember that Windows nodes don't have same JDK or Maven installation names: see https://cwiki.apache.org/confluence/display/INFRA/Jenkins for details Unlike Linus nodes, Windows nodes are not managed with Puppet: discrepency between Windows

Jenkins Build IT's / JenkinsFile

Hi, unfortunately the run of IT's etc. fail often based on similar messages like this: Error: JAVA_HOME is set to an invalid directory. JAVA_HOME = "F:\hudson\tools\java\jdk1.7.0_79-unlimited-security" Please set the JAVA_HOME variable in your environment to match the location of your Java

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

Even if we had a -1 as long as I have the binding votes *as release manager* it would be my call whether to release or not. Now *personally* I much rather release with consensus, but any committer can step up to be release manager for any of our components, so I would prefer if we can agree our

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

Hi, On 26/02/17 12:22, Hervé BOUTEMY wrote: now I see your reasoning 3.3.n were expected to be final quality: they were not, they were dropped (vote result was -1, result sent to trash) That is the difference here. The alpha-1 at the moment does not have any -1 yet...(not that I seen one,

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

FYI, I published the reference documentation http://maven.apache.org/ref/3-LATEST/ just did classical "mvn -Preporting site site:stage" followed by "mvn scm- publish:publish-scm" as defined in documentation [1] once the vote is validated, just follow the next steps to publish the versioned

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

now I see your reasoning 3.3.n were expected to be final quality: they were not, they were dropped (vote result was -1, result sent to trash) 3.5.0-alpha-n is expected to be alpha quality: from tests, we have the alpha quality (IMHO even more quality, but not final quality), then the vote will

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

On Sun, 26 Feb 2017 04:58:24 +0100, Manfred Moser wrote: Imho it should go to Central just like any other release. All components and everything. The version clearly tells thats its alpha and this allows for clean testing, embedding and so on. We have done it

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

>> CLI would print a WARNING, because it shows some strange situation that people didn't expect Duplicates of sys props should be logged with Warning on console. I totally agree with Herve. Good catch, Herve! On Sun, Feb 26, 2017 at 11:20 AM, Hervé BOUTEMY [via Maven] <

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

+1 tested with many builds: it works as well as I expected (near a RC confidence) Let's fix the identified little glitches, and we'll have our 3.5.0 final :) Regards, Hervé Le jeudi 23 février 2017, 16:10:18 CET Stephen Connolly a écrit : > Hi, > > We solved 65 issues: >

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

+1 to release to central there are general questions on what goes into central (and how central contains probably many unused versions of artifacts), but our Maven core release is not the right moment to try to work on every question we ignored until now Regards, Hervé Le samedi 25 février

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

>From my PoV Alpha versions, compared to betas, are those which can be used only with user's risk unlike betas which are stable however need feedback to make them yet official release version. What makes sense among these two versions to deploy alpha to Central? On Sun, Feb 26, 2017 at 4:59 AM,

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

on this, I don't have exactly same opinion: yes, Maven 3.5.0 should behave like Maven 3.3.9, then we should fix Maven as much as possible and not force Surefire ITs to be changed but if Surefire ITs define multiple times the same property on CLI, then use a edge case, removing the demendency on

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

Let's deploy. I don't see any risk to do it. The version name is clear enough to warn people to use it for tests only. (And I am so motivated to update the Jenkins evil plugin ;) ) Le dim. 26 févr. 2017 à 11:00, Karl Heinz Marbaise a écrit : > Hi, > > my opinion is cleary to

Re: [DISCUSS] 3.5.0 alpha/beta's on Central

Hi, my opinion is cleary to deploy to central as we did before...to give others a chance to test. I can often see that many people are automatically downloading Maven from Central (download from Apache dist etc. is not a good idea apart from that blocked) for example with travis, ship-it,