date:20170226

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
name to run. The test is about to be sent or it is sent but the forked jvm
has not handled it.
It seems the call *Process.exec()* does not return and thus
*FlushReceiver *does
not observe *OutputStream *from the call *Process.getOutputStream()*. This
looks like a deadlock.
Yet this is what our internal logs tell us.
After the hanging JVM has timed out, all pending events are immediately
pushed to JVM right on the exit.

We have an idea to use std/err for communication instead of std/out and
then test it on FreeBSD.

If you have a good idea, please create a branch and we will run a test on
FreeBSD.

We are NOT in hurry to commit to master. First of all we should be
convinced we understand the root cause of the issue together and prevent
from it in the future.

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,
resolve placeholders, etc.
Default implementation should be embedded with one field yet which would
determine order of properties to be merged.

On Mon, Feb 27, 2017 at 12:24 AM, Guillaume Boué  wrote:

> "maven.repo.local" is used automatically by maven-verifier to set-up the
> local repository (see https://github.com/apache/mave
> n-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 systemPropertyVariables... But otherwise, yes,
> setting another system property does the job, until someone decides to set
> that one also on the CLI, which would break the test again...
>
> With regard to the user properties, since  is
> "closer" to the IT than the user properties, I'd expect those to win
> conflicts. However, if it is really intended not to do it, I'll see about
> adding a note in the doc http://maven.apache.org/compon
> ents/surefire/maven-failsafe-plugin/examples/system-properties.html. It
> doesn't mention this use-case.
>
> Thanks,
> Guillaume
>
>
> Le 26/02/2017 à 23:56, Tibor Digana a écrit :
>
>> 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
>> systemPropertyVariable refers to Maven property which refers to user's
>> system property - all with same key name. Not following the idiom would
>> break the restriction and property in  remains unchanged.
>>
>> But this is not so easy because this may break the current user's and our
>> internal integration tests.
>> As a solution would be to introduce a config parameter to alter this
>> behavior in Surefire 3.0.
>>
>> Our internal system property key "localRepository" set initially in forked
>> jvm refers to Maven Local Repo.
>> I think you cannot override it, see AbstractSurefireMojo.java L984,
>> however
>> it is different property key.
>>
>> Do you definitely want to use "maven.repo.local"?
>> It looks to me that Arquillian uses "localRepository".
>>
>>
>> your m2  local repository
>>
>>
>>
>>
>> On Sun, Feb 26, 2017 at 11:29 PM, Guillaume Boué-2 [via Maven] <
>> ml-node+s40175n5900380...@n5.nabble.com> wrote:
>>
>> 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 unconditionally after setting the configured
>>> system properties in . Perhaps the user
>>> properties should be set first, and then any systemPropertyVariables?
>>>
>>> I found SUREFIRE-491 about this also.
>>>
>>> Guillaume
>>>
>>> Le 26/02/2017 à 23:03, Tibor Digana a écrit :
>>>
>>> Have you tried this?

 
   ${project.build.directory}/it-repo>>> repo.local>
 

 ...
 maven-failsafe-plugin:

 
  ${maven.repo.local}
 

 On Sun, Feb 26, 2017 at 10:01 PM, Guillaume Boué <[hidden email]

>>> > wrote:
>>>
 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 would like the
>
 system
>>>
 property defined in  to override the one
>
 defined
>>>
 on the CLI during IT execution.
>
> As an example, consider the build of the maven-remote-resources-plugin.
> When trying to run the ITs with a custom local repo set on the CLI
>
 (with
>>>
 -Dmaven.repo.local=...), they all fail because they can't resolve the
> plugin in the version being built. What happens is that, even though
>
 there
>>>
 is
>
> 
>   
> ${project.build.directory}/it-repo repo.local>
>  
>
> in the POM, to force the local repository to point to a location where
>
 the
>>>
 plugin was installed before-hand, it is getting ignored because
> -Dmaven.repo.local was also set on the CLI (and to a location where the
> plugin is rightly not installed). The current workaround I have is to
>
 set a
>>>
 different system property, like , and then use
>
>

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

2017-02-26 Thread Guillaume Boué

"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
systemPropertyVariables... But otherwise, yes, setting another system
property does the job, until someone decides to set that one also on the
CLI, which would break the test again...

With regard to the user properties, since is
"closer" to the IT than the user properties, I'd expect those to win
conflicts. However, if it is really intended not to do it, I'll see
about adding a note in the doc
http://maven.apache.org/components/surefire/maven-failsafe-plugin/examples/system-properties.html.
It doesn't mention this use-case.

Thanks,
Guillaume

Le 26/02/2017 à 23:56, Tibor Digana a écrit :

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
systemPropertyVariable refers to Maven property which refers to user's
system property - all with same key name. Not following the idiom would
break the restriction and property in remains unchanged.

But this is not so easy because this may break the current user's and our
internal integration tests.
As a solution would be to introduce a config parameter to alter this
behavior in Surefire 3.0.

Our internal system property key "localRepository" set initially in forked
jvm refers to Maven Local Repo.
I think you cannot override it, see AbstractSurefireMojo.java L984, however
it is different property key.

Do you definitely want to use "maven.repo.local"?
It looks to me that Arquillian uses "localRepository".

your m2 local repository

On Sun, Feb 26, 2017 at 11:29 PM, Guillaume Boué-2 [via Maven] <
ml-node+s40175n5900380...@n5.nabble.com> wrote:

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 unconditionally after setting the configured
system properties in . Perhaps the user
properties should be set first, and then any systemPropertyVariables?

I found SUREFIRE-491 about this also.

Guillaume

Le 26/02/2017 à 23:03, Tibor Digana a écrit :

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é <[hidden email]

> wrote:

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 would like the

system

property defined in to override the one

defined

on the CLI during IT execution.

As an example, consider the build of the maven-remote-resources-plugin.
When trying to run the ITs with a custom local repo set on the CLI

(with

-Dmaven.repo.local=...), they all fail because they can't resolve the
plugin in the version being built. What happens is that, even though

there

${project.build.directory}/it-repo

in the POM, to force the local repository to point to a location where

the

plugin was installed before-hand, it is getting ignored because
-Dmaven.repo.local was also set on the CLI (and to a location where the
plugin is rightly not installed). The current workaround I have is to

set a

different system property, like , and then use

verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );

in each IT code. But this sounds very brittle since the same issue

could

happen again if someone were to define -DlocalRepositoryPath for any

reason

on the CLI...

Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

-
To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

--
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/Passing-a-system-property-
already-defined-on-CLI-to-Failsafe-Plugin-tp5900361p5900380.html
To start a new topic under Maven

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
systemPropertyVariable refers to Maven property which refers to user's
system property - all with same key name. Not following the idiom would
break the restriction and property in  remains unchanged.

But this is not so easy because this may break the current user's and our
internal integration tests.
As a solution would be to introduce a config parameter to alter this
behavior in Surefire 3.0.

Our internal system property key "localRepository" set initially in forked
jvm refers to Maven Local Repo.
I think you cannot override it, see AbstractSurefireMojo.java L984, however
it is different property key.

Do you definitely want to use "maven.repo.local"?
It looks to me that Arquillian uses "localRepository".

  
   your m2  local repository
  



On Sun, Feb 26, 2017 at 11:29 PM, Guillaume Boué-2 [via Maven] <
ml-node+s40175n5900380...@n5.nabble.com> wrote:

> 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 unconditionally after setting the configured
> system properties in . Perhaps the user
> properties should be set first, and then any systemPropertyVariables?
>
> I found SUREFIRE-491 about this also.
>
> Guillaume
>
> Le 26/02/2017 à 23:03, Tibor Digana a écrit :
>
> > 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é <[hidden email]
> > wrote:
> >
> >> 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 would like the
> system
> >> property defined in  to override the one
> defined
> >> on the CLI during IT execution.
> >>
> >> As an example, consider the build of the maven-remote-resources-plugin.
> >> When trying to run the ITs with a custom local repo set on the CLI
> (with
> >> -Dmaven.repo.local=...), they all fail because they can't resolve the
> >> plugin in the version being built. What happens is that, even though
> there
> >> is
> >>
> >>
> >>  
> >> ${project.build.directory}/it-repo
>
> >> 
> >>
> >> in the POM, to force the local repository to point to a location where
> the
> >> plugin was installed before-hand, it is getting ignored because
> >> -Dmaven.repo.local was also set on the CLI (and to a location where the
> >> plugin is rightly not installed). The current workaround I have is to
> set a
> >> different system property, like , and then use
> >>
> >> verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );
> >>
> >> in each IT code. But this sounds very brittle since the same issue
> could
> >> happen again if someone were to define -DlocalRepositoryPath for any
> reason
> >> on the CLI...
> >>
> >> Guillaume
> >>
> >>
> >> ---
> >> L'absence de virus dans ce courrier électronique a été vérifiée par le
> >> logiciel antivirus Avast.
> >> https://www.avast.com/antivirus
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: [hidden email]
> 
> >> For additional commands, e-mail: [hidden email]
> 
> >>
> >>
> >
>
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Passing-a-system-property-
> already-defined-on-CLI-to-Failsafe-Plugin-tp5900361p5900380.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
>

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

2017-02-26 Thread Guillaume Boué

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 unconditionally after setting the configured
system properties in . Perhaps the user
properties should be set first, and then any systemPropertyVariables?

I found SUREFIRE-491 about this also.

Guillaume

Le 26/02/2017 à 23:03, Tibor Digana a écrit :

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,

As an example, consider the build of the maven-remote-resources-plugin.
When trying to run the ITs with a custom local repo set on the CLI (with
-Dmaven.repo.local=...), they all fail because they can't resolve the
plugin in the version being built. What happens is that, even though there
is

${project.build.directory}/it-repo

in the POM, to force the local repository to point to a location where the
plugin was installed before-hand, it is getting ignored because
-Dmaven.repo.local was also set on the CLI (and to a location where the
plugin is rightly not installed). The current workaround I have is to set a
different system property, like , and then use

verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );

in each IT code. But this sounds very brittle since the same issue could
happen again if someone were to define -DlocalRepositoryPath for any reason
on the CLI...

Guillaume

---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

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 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 would like the system
> property defined in  to override the one defined
> on the CLI during IT execution.
>
> As an example, consider the build of the maven-remote-resources-plugin.
> When trying to run the ITs with a custom local repo set on the CLI (with
> -Dmaven.repo.local=...), they all fail because they can't resolve the
> plugin in the version being built. What happens is that, even though there
> is
>
>   
> 
> ${project.build.directory}/it-repo
>
>
> in the POM, to force the local repository to point to a location where the
> plugin was installed before-hand, it is getting ignored because
> -Dmaven.repo.local was also set on the CLI (and to a location where the
> plugin is rightly not installed). The current workaround I have is to set a
> different system property, like , and then use
>
> verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );
>
> in each IT code. But this sounds very brittle since the same issue could
> happen again if someone were to define -DlocalRepositoryPath for any reason
> on the CLI...
>
> Guillaume
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

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,
>
> 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 would like the
> system property defined in  to override the one
> defined on the CLI during IT execution.
>
> As an example, consider the build of the maven-remote-resources-plugin.
> When trying to run the ITs with a custom local repo set on the CLI (with
> -Dmaven.repo.local=...), they all fail because they can't resolve the
> plugin in the version being built. What happens is that, even though
> there is
>
>
>  
> ${project.build.directory}/it-repo
> 
>
> in the POM, to force the local repository to point to a location where
> the plugin was installed before-hand, it is getting ignored because
> -Dmaven.repo.local was also set on the CLI (and to a location where the
> plugin is rightly not installed). The current workaround I have is to
> set a different system property, like , and then use
>
> verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );
>
> in each IT code. But this sounds very brittle since the same issue could
> happen again if someone were to define -DlocalRepositoryPath for any
> reason on the CLI...
>
> Guillaume
>
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le
> logiciel antivirus Avast.
> https://www.avast.com/antivirus
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/Passing-a-system-property-
> already-defined-on-CLI-to-Failsafe-Plugin-tp5900361.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/Passing-a-system-property-already-defined-on-CLI-to-Failsafe-Plugin-tp5900361p5900369.html
Sent from the Maven Developers mailing list archive at Nabble.com.

Passing a system property already defined on CLI to Failsafe Plugin

2017-02-26 Thread Guillaume Boué


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 would like the
system property defined in  to override the one
defined on the CLI during IT execution.

As an example, consider the build of the maven-remote-resources-plugin.
When trying to run the ITs with a custom local repo set on the CLI (with
-Dmaven.repo.local=...), they all fail because they can't resolve the
plugin in the version being built. What happens is that, even though
there is

  

${project.build.directory}/it-repo
   

in the POM, to force the local repository to point to a location where
the plugin was installed before-hand, it is getting ignored because
-Dmaven.repo.local was also set on the CLI (and to a location where the
plugin is rightly not installed). The current workaround I have is to
set a different system property, like , and then use

verifier.setLocalRepo( System.getProperty( "localRepositoryPath" ) );

in each IT code. But this sounds very brittle since the same issue could
happen again if someone were to define -DlocalRepositoryPath for any
reason on the CLI...

Guillaume


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 std/in in forked JVM. Therefore the forked
JVM is still waiting for class to test. It is not related to

System.out.close(); in ForkedBooter.


On Sun, Feb 26, 2017 at 6:14 PM, Stephen Connolly 
wrote:

> *@stephenc* commented on this pull request.
> --
>
> In maven-surefire-common/src/main/java/org/apache/maven/
> plugin/surefire/report/ConsoleOutputFileReporter.java
> :
>
> > @@ -69,8 +69,8 @@ public void close()
>  {
>  try
>  {
> -fileOutputStream.flush();
> -fileOutputStream.close();
> +// fileOutputStream.flush(); Will not call close on 
exception!
> +fileOutputStream.close(); // Will implicitly flush.
>
> Then the correct way to do that is wrap the flush in another layer of try
> catch (and leave a todo to use addSuppressed once baseline JVM for the 
code
> is Java 7)
>
> â
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>



-- 
Cheers
Tibor



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2017-02-26 Thread stephenc

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 void close()
 {
 try
 {
-fileOutputStream.flush();
-fileOutputStream.close();
+// fileOutputStream.flush(); Will not call close on 
exception!
+fileOutputStream.close(); // Will implicitly flush.
--- End diff --

Then the correct way to do that is wrap the flush in another layer of try 
catch (and leave a todo to use addSuppressed once baseline JVM for the code is 
Java 7)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2017-02-26 Thread ChristianSchulte

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 exit( int returnCode, Shutdown 
shutdownType, CommandReader r
 switch ( shutdownType )
 {
 case KILL:
+System.out.close();
--- End diff --

`System.in` and `System.out` are both 
[`PrintStream`](http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/file/8108ffe38ccb/src/share/classes/java/io/PrintStream.java)s.
 That class already is error prone like mad (autoFlush yes or no, checkError 
instead of throwing exceptions, etc.). It internally creates a `BufferedWriter` 
used for writing characters. I haven't found anything in the JDK flushing those 
buffers so it seems this is up to the application. I am quite sure that closing 
those streams manually is correct. That's what you would do in a C application 
as well.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2017-02-26 Thread ChristianSchulte

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 @@ public void close()
 {
 try
 {
-fileOutputStream.flush();
-fileOutputStream.close();
+// fileOutputStream.flush(); Will not call close on 
exception!
+fileOutputStream.close(); // Will implicitly flush.
--- End diff --

I just wanted to be sure that `close` is always called. See the comment. 
When `flush` throws an exception, `close` will never be called and leak 
resources.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2017-02-26 Thread ChristianSchulte

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 @@ public void testSetCompleted( WrappedReportEntry 
testSetReportEntry, TestSetStat
 }
 ppw.endElement(); // TestSuite
 }
+catch ( final IOException e )
+{
+throw new ReporterException( "Failure generating XML report.", 
e );
--- End diff --

I started a surefire build and then left because it runs a long time and I 
did not want to wait. There were a couple of ITs no longer failing. I'll write 
an email when getting home. Results looked promising on OpenBSD. Last commit is 
just temporary for testing. I closed various maven-shared-utils issues today 
which seem to fix things for surefire as well. I'll send an email when I am 
back. I hope the console will show a successful build. 


[CommandLineUtils](http://svn.apache.org/viewvc?view=revision=1784432)
[StreamFeeder](http://svn.apache.org/viewvc?view=revision=1784431)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 returnCode, Shutdown 
shutdownType, CommandReader r
 switch ( shutdownType )
 {
 case KILL:
+System.out.close();
--- End diff --

The logs show me that `Process.exec()` is blocked with maybe read() method 
in another Thread, and maybe a kind of deadlock which means using error stream 
might be a good try.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 void close()
 {
 try
 {
-fileOutputStream.flush();
-fileOutputStream.close();
+// fileOutputStream.flush(); Will not call close on 
exception!
+fileOutputStream.close(); // Will implicitly flush.
--- End diff --

Writer needs close() without flush() but FileOutputStream does not have 
implicit flush while closing. Javadoc does not mention it. Implementation in 
Oracle JDK is maybe different and probably flushes on close but that's this JVM 
vendor.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 returnCode, Shutdown 
shutdownType, CommandReader r
 switch ( shutdownType )
 {
 case KILL:
+System.out.close();
--- End diff --

@ChristianSchulte 
This is executed right before JVM exit.
But our problem is in the beginning of life time of JVM.
This means the `InputStream.read()` and (`Process.waitFor()` or 
`Process.exec()`) are mutual exclusive on FreeBSD according to logs.
It seems std/err will be tested instead of std/out.
Additionally ACK before shutdown needs to be added as StephenC mentioned.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[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 void testSetCompleted( WrappedReportEntry 
testSetReportEntry, TestSetStat
 }
 ppw.endElement(); // TestSuite
 }
+catch ( final IOException e )
+{
+throw new ReporterException( "Failure generating XML report.", 
e );
--- End diff --

@ChristianSchulte 
Pls do not commit. I have stash with explanation.
Later. First of all is to test freebasd.
I have fixed testng system properties in a branch but have not commit it to 
the branch. We will test it. But later in the evening.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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
> 
>  * Self-enclosing elements are disallowed so  should be used instead of
>  * Custom tags cannot start with a dot anymore
> (http://stackoverflow.com/q/28726294) * A link to a non-existent class
> generates an error and not a warning anymore (but only with Oracle JDK 8,
> not OpenJDK 8)
> 
> Modified:
>
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/application/sr
> c/main/java/app/App.java
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/library/module
> -a/src/main/java/aaa/App.java
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/library/module
> -b/src/main/java/bbb/App.java
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/pom.xml
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-278/src/main/java/
> com/mycompany/myapp/App.java
> maven/plugins/trunk/maven-javadoc-plugin/src/it/dependencySource-3/MJAVADOC
> -280-3-modA/pom.xml
> maven/plugins/trunk/maven-javadoc-plugin/src/it/dependencySource-3/MJAVADOC
> -280-3-modA/src/main/java/org/apache/maven/plugins/mjavadoc/it/moda/App.java
> maven/plugins/trunk/maven-javadoc-plugin/src/it/dependencySource-3/MJAVADOC
> -280-3-modB/pom.xml
> maven/plugins/trunk/maven-javadoc-plugin/src/it/dependencySource-3/MJAVADOC
> -280-3-modB/src/main/java/org/apache/maven/plugins/mjavadoc/it/modb/App.java
> maven/plugins/trunk/maven-javadoc-plugin/src/it/dependencySource-4/MJAVADOC
> -280-4-projects/MJAVADOC-280-4-modA/src/main/java/org/apache/maven/plugins/m
> javadoc/it/moda/App.java
> maven/plugins/trunk/maven-javadoc-plugin/src/it/dependencySource-4/MJAVADOC
> -280-4-projects/MJAVADOC-280-4-modB/src/main/java/org/apache/maven/plugins/m
> javadoc/it/modb/App.java
> maven/plugins/trunk/maven-javadoc-plugin/src/it/dependencySource-4/MJAVADOC
> -280-4-projects/pom.xml
> maven/plugins/trunk/maven-javadoc-plugin/src/it/detectLinks/pom.xml
> 
> Modified:
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/application/sr
> c/main/java/app/App.java URL:
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/i
> t/MJAVADOC-181/application/src/main/java/app/App.java?rev=1784413=1784412
> =1784413=diff
> ===
> === ---
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/application/sr
> c/main/java/app/App.java (original) +++
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/application/sr
> c/main/java/app/App.java Sun Feb 26 00:55:45 2017 @@ -22,10 +22,10 @@
> package app;
>  /**
>   * Hello world class.
>   *
> - * @.fooA 1st custom javadoc tag.
> + * @m.fooA 1st custom javadoc tag.
>   * @author  Me
>   * @version 1st
> - * @.barA 2nd custom javadoc tag.
> + * @m.barA 2nd custom javadoc tag.
>   * @see String#startsWith(String)
>   */
>  public class App
> @@ -33,7 +33,7 @@ public class App
>  /**
>   * Hello world method.
>   *
> - * @.fooA 1st custom javadoc tag.
> + * @m.fooA 1st custom javadoc tag.
>   * @see String#endsWith(String)
>   */
>  public static void main( String[] args )
> 
> Modified:
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/library/module
> -a/src/main/java/aaa/App.java URL:
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/i
> t/MJAVADOC-181/library/module-a/src/main/java/aaa/App.java?rev=1784413=17
> 84412=1784413=diff
> ===
> === ---
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/library/module
> -a/src/main/java/aaa/App.java (original) +++
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/library/module
> -a/src/main/java/aaa/App.java Sun Feb 26 00:55:45 2017 @@ -22,10 +22,10 @@
> package aaa;
>  /**
>   * Hello world class.
>   *
> - * @.fooA 1st custom javadoc tag.
> + * @m.fooA 1st custom javadoc tag.
>   * @author  Me
>   * @version 1st
> - * @.barA 2nd custom javadoc tag.
> + * @m.barA 2nd custom javadoc tag.
>   * @see String#startsWith(String)
>   */
>  public class App
> @@ -33,7 +33,7 @@ public class App
>  /**
>   * Hello world method.
>   *
> - * @.fooA 1st custom javadoc tag.
> + * @m.fooA 1st custom javadoc tag.
>   * @see String#endsWith(String)
>   */
>  public static void main( String[] args )
> 
> Modified:
> maven/plugins/trunk/maven-javadoc-plugin/src/it/MJAVADOC-181/library/module
> -b/src/main/java/bbb/App.java URL:
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/i
> t/MJAVADOC-181/library/module-b/src/main/java/bbb/App.java?rev=1784413=17
>

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 effectively passing through
> the parsed options
> On Sun 26 Feb 2017 at 12:59, Tibor Digana <[hidden email]
> >
> wrote:
>
> > @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 system properties.
> >
> >
> >
> > On Thu, Feb 23, 2017 at 5:10 PM, Stephen Connolly <
> > [hidden email] >
> wrote:
> >
> > > Hi,
> > >
> > > We solved 65 issues:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > projectId=12316922=12339664=Text
> > >
> > > There are still a couple of issues left in JIRA for 3.5.0, but I do
> not
> > > think any of those are blocking an alpha release:
> > > https://issues.apache.org/jira/issues/?jql=project%20%;>
> https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%
> > > 20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%
> > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >
> > > In addition there are 315 issues left in JIRA for Maven core:
> > > https://issues.apache.org/jira/issues/?jql=project%20%;>
> https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1324
> > >
> > > The distributable binaries and sources for testing can be found here:
> > > https://repository.apache.org/content/repositories/maven-
> > > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/
> > >
> > > Specifically the zip, tarball, and source archives can be found here:
> > > https://repository.apache.org/content/repositories/maven-
> > > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> > > maven-3.5.0-alpha-1-bin.zip
> > > https://repository.apache.org/content/repositories/maven-
> > > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> > > maven-3.5.0-alpha-1-bin.tar.gz
> > > https://repository.apache.org/content/repositories/maven-
> > > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> > > maven-3.5.0-alpha-1-src.zip
> > > https://repository.apache.org/content/repositories/maven-
> > > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> > > maven-3.5.0-alpha-1-src.tar.gz
> > >
> > > Source release checksum(s):
> > > apache-maven-3.5.0-alpha-1-src.tar.gz sha1:
> > > 6055696aece5b0bfdd0308dae60838b37e218aba
> > > apache-maven-3.5.0-alpha-1-src.zip sha1:
> > > 7d6adcdf8929205bf20399c71c6a2bdb9ee4f6dd
> > >
> > > Git tag:
> > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > > 8e6bbc4d4aa7cdc837625a05358c98ca15f72698
> > >
> > > Staging site:
> > > https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/
> > >
> > > Vote open for 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > > Thanks,
> > > -Stephen
> > >
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
> --
> Sent from my phone
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-3-5-0-alpha-1-
> tp5899775p5900267.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-3-5-0-alpha-1-tp5899775p5900270.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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

2017-02-26 Thread Stephen Connolly

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 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 system properties.
>
>
>
> On Thu, Feb 23, 2017 at 5:10 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Hi,
> >
> > We solved 65 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12316922=12339664=Text
> >
> > There are still a couple of issues left in JIRA for 3.5.0, but I do not
> > think any of those are blocking an alpha release:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%
> > 20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%
> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > In addition there are 315 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1324
> >
> > The distributable binaries and sources for testing can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/
> >
> > Specifically the zip, tarball, and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-
> > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> > maven-3.5.0-alpha-1-bin.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> > maven-3.5.0-alpha-1-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-
> > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> > maven-3.5.0-alpha-1-src.zip
> > https://repository.apache.org/content/repositories/maven-
> > 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> > maven-3.5.0-alpha-1-src.tar.gz
> >
> > Source release checksum(s):
> > apache-maven-3.5.0-alpha-1-src.tar.gz sha1:
> > 6055696aece5b0bfdd0308dae60838b37e218aba
> > apache-maven-3.5.0-alpha-1-src.zip sha1:
> > 7d6adcdf8929205bf20399c71c6a2bdb9ee4f6dd
> >
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> > 8e6bbc4d4aa7cdc837625a05358c98ca15f72698
> >
> > Staging site:
> > https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Thanks,
> > -Stephen
> >
>
>
>
> --
> Cheers
> Tibor
>
-- 
Sent from my phone

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 system properties.



On Thu, Feb 23, 2017 at 5:10 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Hi,
>
> We solved 65 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12316922=12339664=Text
>
> There are still a couple of issues left in JIRA for 3.5.0, but I do not
> think any of those are blocking an alpha release:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20AND%
> 20fixVersion%20in%20(3.5.0%2C%203.5.0-candidate)%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> In addition there are 315 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%
> 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1324
>
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/
>
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> maven-3.5.0-alpha-1-bin.zip
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> maven-3.5.0-alpha-1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> maven-3.5.0-alpha-1-src.zip
> https://repository.apache.org/content/repositories/maven-
> 1324/org/apache/maven/apache-maven/3.5.0-alpha-1/apache-
> maven-3.5.0-alpha-1-src.tar.gz
>
> Source release checksum(s):
> apache-maven-3.5.0-alpha-1-src.tar.gz sha1:
> 6055696aece5b0bfdd0308dae60838b37e218aba
> apache-maven-3.5.0-alpha-1-src.zip sha1:
> 7d6adcdf8929205bf20399c71c6a2bdb9ee4f6dd
>
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 8e6bbc4d4aa7cdc837625a05358c98ca15f72698
>
> Staging site:
> https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Thanks,
> -Stephen
>



-- 
Cheers
Tibor

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 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 nodes may happen, since humans are humans...

Regards,

Hervé

Le dimanche 26 février 2017, 13:17:01 CET Karl Heinz Marbaise a écrit :

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 installation.

Error: JAVA_HOME is set to an invalid directory.
JAVA_HOME = "F:\hudson\tools\java\jdk1.8.0_92-unlimited-security"
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.

On the following nodes:

Running on windows-2012-3 in
f:\jenkins\jenkins-slave\workspace\en-3.x-jenkinsfile_MNG-6170-OM3ZXWO5UNVMM
FFPGOLYVV3V3JRE5DV7NEVDHAME7MV3CTPRN5UA


It looks like there are missing installations of the appropriate JDK's
which are needed for building..

Is there somewhere a list of installed JDK's on the machines? Or should
we inform INFRA about this issue?

Kind regards
Karl Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2017-02-26 Thread Christian Schulte

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 of our components, so I would
> prefer if we can agree our current position (which we can agree to change
> in the future if needed) and just run with that.
> 
> For me:
> 
> * alpha is also about saying "we are not closed to adding something else
> before beta... but we will think hard on any proposed additions"
> 
> * beta is about saying "only important bug fixes... or really low risk bug
> fixes after careful evaluation"
> 
> * RC is "last chance to find showstoppers only"... if no showstopper then
> we drop and cut the release for real
> 

We should document that somewhere. I am used to some different meaning.

alpha:
Development not finished yet. More commits to come. Everything can
happen. It's just a label external entities can refer to in a stable way
(like in JIRA - instead of having to refer to e.g. the snapshot from
yesterday 3 hours after commit xyz). The classifier could as well be an
SCM id (like -alpha-svnrevision or -alpha-uglygithash).

beta:
Development is finished. Seeking for testing. Developers will only fix
bugs, if there are any. Just the final steps needed to get things ready
for release.

RC:
Same meaning Stephen described. The RC already is the final release.
When the SCM allows it, you normally rename the RC tag removing the RC
and just rebuild that for the final release. This is what you will be
paying for. Point of no return. Nothing can be removed afterwards - just
deprecations or additions to come in the next development cycle. Seeking
for a major review/final testing.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Jenkins Build IT's / JenkinsFile

2017-02-26 Thread Stephen Connolly

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 resolveScm and infra to
install Cyrille's withMaven plugin (pipeline-maven)

On Sun 26 Feb 2017 at 12:17, Karl Heinz Marbaise  wrote:

> 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 installation.
>
> Error: JAVA_HOME is set to an invalid directory.
> JAVA_HOME = "F:\hudson\tools\java\jdk1.8.0_92-unlimited-security"
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
>
> On the following nodes:
>
> Running on windows-2012-3 in
>
> f:\jenkins\jenkins-slave\workspace\en-3.x-jenkinsfile_MNG-6170-OM3ZXWO5UNVMMFFPGOLYVV3V3JRE5DV7NEVDHAME7MV3CTPRN5UA
>
>
> It looks like there are missing installations of the appropriate JDK's
> which are needed for building..
>
> Is there somewhere a list of installed JDK's on the machines? Or should
> we inform INFRA about this issue?
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

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 nodes may happen, since humans are humans...

Regards,

Hervé

Le dimanche 26 février 2017, 13:17:01 CET Karl Heinz Marbaise a écrit :
> 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 installation.
> 
> Error: JAVA_HOME is set to an invalid directory.
> JAVA_HOME = "F:\hudson\tools\java\jdk1.8.0_92-unlimited-security"
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> 
> On the following nodes:
> 
> Running on windows-2012-3 in
> f:\jenkins\jenkins-slave\workspace\en-3.x-jenkinsfile_MNG-6170-OM3ZXWO5UNVMM
> FFPGOLYVV3V3JRE5DV7NEVDHAME7MV3CTPRN5UA
> 
> 
> It looks like there are missing installations of the appropriate JDK's
> which are needed for building..
> 
> Is there somewhere a list of installed JDK's on the machines? Or should
> we inform INFRA about this issue?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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 installation.

Error: JAVA_HOME is set to an invalid directory.
JAVA_HOME = "F:\hudson\tools\java\jdk1.8.0_92-unlimited-security"
Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.

On the following nodes:

Running on windows-2012-3 in 
f:\jenkins\jenkins-slave\workspace\en-3.x-jenkinsfile_MNG-6170-OM3ZXWO5UNVMMFFPGOLYVV3V3JRE5DV7NEVDHAME7MV3CTPRN5UA



It looks like there are missing installations of the appropriate JDK's 
which are needed for building..


Is there somewhere a list of installed JDK's on the machines? Or should 
we inform INFRA about this issue?


Kind regards
Karl Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2017-02-26 Thread 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 of our components, so I would
prefer if we can agree our current position (which we can agree to change
in the future if needed) and just run with that.

For me:

* alpha is also about saying "we are not closed to adding something else
before beta... but we will think hard on any proposed additions"

* beta is about saying "only important bug fixes... or really low risk bug
fixes after careful evaluation"

* RC is "last chance to find showstoppers only"... if no showstopper then
we drop and cut the release for real

On Sun 26 Feb 2017 at 11:48, Karl Heinz Marbaise  wrote:

> 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, correct please if I'm oversight
> something)...
>
> So it should be released and published to central.
>
> If we have a -1 than this shouldn't be published to central cause we
> have found issues which prevent using as a release...
>
>
> >
> > 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 be
> > positive *for an alpha* and we'll publish the result
>
> Agreed..
>
>
> Kind regards
> Karl Heinz Marbaise
>
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 26 février 2017, 11:44:48 CET Robert Scholte a écrit :
> >> 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 in the past and I dont see any reason for changing
> this.
> >>
> >> Well, Karl Heinz's link only shows those which were deployed, not the
> ones
> >> which weren't.
> >> Also, we've skipped a lot of versions in the 3.3.x, because we had a
> >> different approach: just make that 3.3.n and simply burn it if there are
> >> issues. We could have called this release 3.5.0, we see some issues and
> >> decide if that should block the release.
> >>
> >> The jansi temp files might be a blocker for me if we are going to
> publish
> >> this version.
> >>
> >> Robert
> >>
> >>> Manfred
> >>>
> >>> Stephen Connolly wrote on 2017-02-25 16:05:
>  So if I am embedding Maven, how do I embed Maven 3.5.0-alpha-1?
> 
>  (I know it should not be a big issue as we should have the release
> soon
>  anyway, but more from the principal POV)
> 
>  Consider the Jenkins "evil" job type plugin that has dependencies on
>  some
>  of the artifacts that are in the staging repository? If there is a
> need
>  to
>  update the adapter libs for that to work with alpha-1, how would that
> be
>  possible if we don't publish the artifacts at least somewhere?
>  On Sat 25 Feb 2017 at 23:23, Robert Scholte 
> 
>  wrote:
> > It depends on what the task of Central is. If it for *dependencies*,
> > there's no need to publish pre-final versions; don't think we should
> > motive plugins to depend on alphas.
> >
> > AFAIK the common way to get a new version of Maven is via
> > http://maven.apache.org/download.cgi and not via Central.
> >
> > This is also about hygiene. Not every artifact belongs in Central
> > (we've
> > seen continuous deployment-like releases), and pre-releases could
> > belong
> > to that group.
> >
> > Funny, just like Jigsaw there's a clear difference between libraries
> > and
> > applications; I don't mind treating them differently, especially in
> > these
> > unofficial release stages.
> >
> > Robert
> >
> > On Sat, 25 Feb 2017 22:55:55 +0100, Karl Heinz Marbaise
> >
> >  wrote:
> >> Hi,
> >>
> >> based on the started discussion about either to bring 3.5.0-alpha-1
> >
> > to
> >
> >> Central or not I would suggest to discuss in a separate thread and
> >> prevent using the VOTE's threads for that (as Stephen already
> >
> > mentioned).
> >
> >> Using Central:
> >>   o Everybody can use it and make tests on it.
> >>
> >> Using an other repository:
> >>   o Which one?
> >>
> >> Using only dist area? Or something different?
> >>
> >> WDY?
> >
> >> Based on earlier releases which had been in Central with alpha's:
> >
>

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, correct please if I'm oversight something)...


So it should be released and published to central.

If we have a -1 than this shouldn't be published to central cause we 
have found issues which prevent using as a release...





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 be
positive *for an alpha* and we'll publish the result


Agreed..


Kind regards
Karl Heinz Marbaise



Regards,

Hervé

Le dimanche 26 février 2017, 11:44:48 CET Robert Scholte a écrit :

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 in the past and I dont see any reason for changing this.


Well, Karl Heinz's link only shows those which were deployed, not the ones
which weren't.
Also, we've skipped a lot of versions in the 3.3.x, because we had a
different approach: just make that 3.3.n and simply burn it if there are
issues. We could have called this release 3.5.0, we see some issues and
decide if that should block the release.

The jansi temp files might be a blocker for me if we are going to publish
this version.

Robert


Manfred

Stephen Connolly wrote on 2017-02-25 16:05:

So if I am embedding Maven, how do I embed Maven 3.5.0-alpha-1?

(I know it should not be a big issue as we should have the release soon
anyway, but more from the principal POV)

Consider the Jenkins "evil" job type plugin that has dependencies on
some
of the artifacts that are in the staging repository? If there is a need
to
update the adapter libs for that to work with alpha-1, how would that be
possible if we don't publish the artifacts at least somewhere?
On Sat 25 Feb 2017 at 23:23, Robert Scholte 

wrote:

It depends on what the task of Central is. If it for *dependencies*,
there's no need to publish pre-final versions; don't think we should
motive plugins to depend on alphas.

AFAIK the common way to get a new version of Maven is via
http://maven.apache.org/download.cgi and not via Central.

This is also about hygiene. Not every artifact belongs in Central
(we've
seen continuous deployment-like releases), and pre-releases could
belong
to that group.

Funny, just like Jigsaw there's a clear difference between libraries
and
applications; I don't mind treating them differently, especially in
these
unofficial release stages.

Robert

On Sat, 25 Feb 2017 22:55:55 +0100, Karl Heinz Marbaise

 wrote:

Hi,

based on the started discussion about either to bring 3.5.0-alpha-1


to


Central or not I would suggest to discuss in a separate thread and
prevent using the VOTE's threads for that (as Stephen already


mentioned).


Using Central:
  o Everybody can use it and make tests on it.

Using an other repository:
  o Which one?

Using only dist area? Or something different?

WDY?



Based on earlier releases which had been in Central with alpha's:

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%2
0AND%20a%3A%22apache-maven%22>>>

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--


Sent from my phone


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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 reference documentation from the staging area

Regards,

Hervé

[1] 
http://maven.apache.org/developers/website/deploy-component-reference-documentation.html#Staging_component_reference_documentation

Le dimanche 26 février 2017, 11:32:48 CET Hervé BOUTEMY a écrit :
> +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:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922;
> > ve rsion=12339664=Text
> > 
> > There are still a couple of issues left in JIRA for 3.5.0, but I do not
> > think any of those are blocking an alpha release:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20res
> > ol
> > ution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(3.5.0%2C%203.5.0-cand
> > ida te)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > 
> > In addition there are 315 issues left in JIRA for Maven core:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20res
> > ol
> > ution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C
> > %20 created%20ASC
> > 
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1324
> > 
> > The distributable binaries and sources for testing can be found here:
> > https://repository.apache.org/content/repositories/maven-1324/org/apache/m
> > av en/apache-maven/3.5.0-alpha-1/
> > 
> > Specifically the zip, tarball, and source archives can be found here:
> > https://repository.apache.org/content/repositories/maven-1324/org/apache/m
> > av en/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-bin.zip
> > https://repository.apache.org/content/repositories/maven-1324/org/apache/m
> > a
> > ven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-bin.tar.gz
> > https://repository.apache.org/content/repositories/maven-1324/org/apache/m
> > a
> > ven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-src.zip
> > https://repository.apache.org/content/repositories/maven-1324/org/apache/m
> > a
> > ven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-src.tar.gz
> > 
> > Source release checksum(s):
> > apache-maven-3.5.0-alpha-1-src.tar.gz sha1:
> > 6055696aece5b0bfdd0308dae60838b37e218aba
> > apache-maven-3.5.0-alpha-1-src.zip sha1:
> > 7d6adcdf8929205bf20399c71c6a2bdb9ee4f6dd
> > 
> > Git tag:
> > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8e6bbc4d4aa
> > 7c dc837625a05358c98ca15f72698
> > 
> > Staging site:
> > https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/
> > 
> > Vote open for 72 hours.
> > 
> > [ ] +1
> > [ ] +0
> > [ ] -1
> > 
> > 
> > Thanks,
> > -Stephen
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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 be 
positive *for an alpha* and we'll publish the result

Regards,

Hervé

Le dimanche 26 février 2017, 11:44:48 CET Robert Scholte a écrit :
> 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 in the past and I dont see any reason for changing this.
> 
> Well, Karl Heinz's link only shows those which were deployed, not the ones
> which weren't.
> Also, we've skipped a lot of versions in the 3.3.x, because we had a
> different approach: just make that 3.3.n and simply burn it if there are
> issues. We could have called this release 3.5.0, we see some issues and
> decide if that should block the release.
> 
> The jansi temp files might be a blocker for me if we are going to publish
> this version.
> 
> Robert
> 
> > Manfred
> > 
> > Stephen Connolly wrote on 2017-02-25 16:05:
> >> So if I am embedding Maven, how do I embed Maven 3.5.0-alpha-1?
> >> 
> >> (I know it should not be a big issue as we should have the release soon
> >> anyway, but more from the principal POV)
> >> 
> >> Consider the Jenkins "evil" job type plugin that has dependencies on
> >> some
> >> of the artifacts that are in the staging repository? If there is a need
> >> to
> >> update the adapter libs for that to work with alpha-1, how would that be
> >> possible if we don't publish the artifacts at least somewhere?
> >> On Sat 25 Feb 2017 at 23:23, Robert Scholte 
> >> 
> >> wrote:
> >>> It depends on what the task of Central is. If it for *dependencies*,
> >>> there's no need to publish pre-final versions; don't think we should
> >>> motive plugins to depend on alphas.
> >>> 
> >>> AFAIK the common way to get a new version of Maven is via
> >>> http://maven.apache.org/download.cgi and not via Central.
> >>> 
> >>> This is also about hygiene. Not every artifact belongs in Central
> >>> (we've
> >>> seen continuous deployment-like releases), and pre-releases could
> >>> belong
> >>> to that group.
> >>> 
> >>> Funny, just like Jigsaw there's a clear difference between libraries
> >>> and
> >>> applications; I don't mind treating them differently, especially in
> >>> these
> >>> unofficial release stages.
> >>> 
> >>> Robert
> >>> 
> >>> On Sat, 25 Feb 2017 22:55:55 +0100, Karl Heinz Marbaise
> >>> 
> >>>  wrote:
> >>> > Hi,
> >>> > 
> >>> > based on the started discussion about either to bring 3.5.0-alpha-1
> >>> 
> >>> to
> >>> 
> >>> > Central or not I would suggest to discuss in a separate thread and
> >>> > prevent using the VOTE's threads for that (as Stephen already
> >>> 
> >>> mentioned).
> >>> 
> >>> > Using Central:
> >>> >   o Everybody can use it and make tests on it.
> >>> > 
> >>> > Using an other repository:
> >>> >   o Which one?
> >>> > 
> >>> > Using only dist area? Or something different?
> >>> > 
> >>> > WDY?
> >>> 
> >>> > Based on earlier releases which had been in Central with alpha's:
> >>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%2
> >>> 0AND%20a%3A%22apache-maven%22>>> 
> >>> > Kind regards
> >>> > Karl Heinz Marbaise
> >>> > 
> >>> > -
> >>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> > For additional commands, e-mail: dev-h...@maven.apache.org
> >>> 
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>> 
> >>> --
> >> 
> >> Sent from my phone
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2017-02-26 Thread Robert Scholte

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 in the past and I dont see any reason for changing this.

Well, Karl Heinz's link only shows those which were deployed, not the ones  
which weren't.
Also, we've skipped a lot of versions in the 3.3.x, because we had a  
different approach: just make that 3.3.n and simply burn it if there are  
issues. We could have called this release 3.5.0, we see some issues and  
decide if that should block the release.

The jansi temp files might be a blocker for me if we are going to publish  
this version.

Robert

Manfred

Stephen Connolly wrote on 2017-02-25 16:05:

So if I am embedding Maven, how do I embed Maven 3.5.0-alpha-1?

(I know it should not be a big issue as we should have the release soon
anyway, but more from the principal POV)

Consider the Jenkins "evil" job type plugin that has dependencies on  
some
of the artifacts that are in the staging repository? If there is a need  
to

update the adapter libs for that to work with alpha-1, how would that be
possible if we don't publish the artifacts at least somewhere?
On Sat 25 Feb 2017 at 23:23, Robert Scholte   
wrote:

It depends on what the task of Central is. If it for *dependencies*,
there's no need to publish pre-final versions; don't think we should
motive plugins to depend on alphas.

AFAIK the common way to get a new version of Maven is via
http://maven.apache.org/download.cgi and not via Central.

This is also about hygiene. Not every artifact belongs in Central  
(we've
seen continuous deployment-like releases), and pre-releases could  
belong

to that group.

Funny, just like Jigsaw there's a clear difference between libraries  
and
applications; I don't mind treating them differently, especially in  
these

unofficial release stages.

Robert

On Sat, 25 Feb 2017 22:55:55 +0100, Karl Heinz Marbaise
 wrote:

> Hi,
>
> based on the started discussion about either to bring 3.5.0-alpha-1  
to

> Central or not I would suggest to discuss in a separate thread and
> prevent using the VOTE's threads for that (as Stephen already  
mentioned).

>
> Using Central:
>   o Everybody can use it and make tests on it.
>
> Using an other repository:
>   o Which one?
>
> Using only dist area? Or something different?
>
> WDY?
>
> Based on earlier releases which had been in Central with alpha's:
>
>
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22apache-maven%22
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--

Sent from my phone

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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] <
ml-node+s40175n5900192...@n5.nabble.com> wrote:

> 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 this edge case would not be a bad
> idea:
> in fact, I'd expect in a future Maven version that such multiple
> definition of
> a property on CLI would print a WARNING, because it shows some strange
> situation that people didn't expect
>
> Regards,
>
> Hervé
>
> Le dimanche 26 février 2017, 07:03:05 CET Christian Schulte a écrit :
>
> > Am 02/25/17 um 17:25 schrieb Tibor Digana:
> > >>> There are two commits for MNG-6078 part of -alpha-1.
> > >
> > > This was caused by system property duplicates in surefire ITs.
> > > It is already fixed in a branch SUREFIRE_SYSPROP_DUPLICATES.
> >
> > If something works with 3.3.9 but not 3.5.0, we need to fix it in Maven.
> > I think this is what Stephen did. No need to "fix" surefire ITs, if they
> > were working with 3.3.9 before. 3.5.0 would not be a drop in replacement
> > anymore that way.
> >
> > Regards,
>
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-3-5-0-alpha-1-
> tp5899775p5900192.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/VOTE-Release-Apache-Maven-3-5-0-alpha-1-tp5899775p5900216.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922
> rsion=12339664=Text
> 
> There are still a couple of issues left in JIRA for 3.5.0, but I do not
> think any of those are blocking an alpha release:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resol
> ution%20%3D%20Unresolved%20AND%20fixVersion%20in%20(3.5.0%2C%203.5.0-candida
> te)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> 
> In addition there are 315 issues left in JIRA for Maven core:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resol
> ution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20
> created%20ASC
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1324
> 
> The distributable binaries and sources for testing can be found here:
> https://repository.apache.org/content/repositories/maven-1324/org/apache/mav
> en/apache-maven/3.5.0-alpha-1/
> 
> Specifically the zip, tarball, and source archives can be found here:
> https://repository.apache.org/content/repositories/maven-1324/org/apache/mav
> en/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-bin.zip
> https://repository.apache.org/content/repositories/maven-1324/org/apache/ma
> ven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-bin.tar.gz
> https://repository.apache.org/content/repositories/maven-1324/org/apache/ma
> ven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-src.zip
> https://repository.apache.org/content/repositories/maven-1324/org/apache/ma
> ven/apache-maven/3.5.0-alpha-1/apache-maven-3.5.0-alpha-1-src.tar.gz
> 
> Source release checksum(s):
> apache-maven-3.5.0-alpha-1-src.tar.gz sha1:
> 6055696aece5b0bfdd0308dae60838b37e218aba
> apache-maven-3.5.0-alpha-1-src.zip sha1:
> 7d6adcdf8929205bf20399c71c6a2bdb9ee4f6dd
> 
> Git tag:
> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8e6bbc4d4aa7c
> dc837625a05358c98ca15f72698
> 
> Staging site:
> https://people.apache.org/~stephenc/maven-3.5.0-alpha-1/
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> Thanks,
> -Stephen



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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 2017, 22:55:55 CET Karl Heinz Marbaise a écrit :
> Hi,
> 
> based on the started discussion about either to bring 3.5.0-alpha-1 to
> Central or not I would suggest to discuss in a separate thread and
> prevent using the VOTE's threads for that (as Stephen already mentioned).
> 
> Using Central:
>   o Everybody can use it and make tests on it.
> 
> Using an other repository:
>   o Which one?
> 
> Using only dist area? Or something different?
> 
> WDY?
> 
> Based on earlier releases which had been in Central with alpha's:
> 
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND
> %20a%3A%22apache-maven%22
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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, Manfred Moser-4 [via Maven] <
ml-node+s40175n5900156...@n5.nabble.com> 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 in the past and I dont see any reason for changing this.
>
> Manfred
>
> Stephen Connolly wrote on 2017-02-25 16:05:
>
> > So if I am embedding Maven, how do I embed Maven 3.5.0-alpha-1?
> >
> > (I know it should not be a big issue as we should have the release soon
> > anyway, but more from the principal POV)
> >
> > Consider the Jenkins "evil" job type plugin that has dependencies on
> some
> > of the artifacts that are in the staging repository? If there is a need
> to
> > update the adapter libs for that to work with alpha-1, how would that be
> > possible if we don't publish the artifacts at least somewhere?
> > On Sat 25 Feb 2017 at 23:23, Robert Scholte <[hidden email]
> > wrote:
> >
> >> It depends on what the task of Central is. If it for *dependencies*,
> >> there's no need to publish pre-final versions; don't think we should
> >> motive plugins to depend on alphas.
> >>
> >> AFAIK the common way to get a new version of Maven is via
> >> http://maven.apache.org/download.cgi and not via Central.
> >>
> >> This is also about hygiene. Not every artifact belongs in Central
> (we've
> >> seen continuous deployment-like releases), and pre-releases could
> belong
> >> to that group.
> >>
> >> Funny, just like Jigsaw there's a clear difference between libraries
> and
> >> applications; I don't mind treating them differently, especially in
> these
> >> unofficial release stages.
> >>
> >> Robert
> >>
> >> On Sat, 25 Feb 2017 22:55:55 +0100, Karl Heinz Marbaise
> >> <[hidden email] >
> wrote:
> >>
> >> > Hi,
> >> >
> >> > based on the started discussion about either to bring 3.5.0-alpha-1
> to
> >> > Central or not I would suggest to discuss in a separate thread and
> >> > prevent using the VOTE's threads for that (as Stephen already
> mentioned).
> >> >
> >> > Using Central:
> >> >   o Everybody can use it and make tests on it.
> >> >
> >> > Using an other repository:
> >> >   o Which one?
> >> >
> >> > Using only dist area? Or something different?
> >> >
> >> > WDY?
> >> >
> >> > Based on earlier releases which had been in Central with alpha's:
> >> >
> >> >
> >> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.
> apache.maven%22%20AND%20a%3A%22apache-maven%22
> >> >
> >> > Kind regards
> >> > Karl Heinz Marbaise
> >> >
> >> > -
>
> >> > To unsubscribe, e-mail: [hidden email]
> 
> >> > For additional commands, e-mail: [hidden email]
> 
> >>
> >> -
> >> To unsubscribe, e-mail: [hidden email]
> 
> >> For additional commands, e-mail: [hidden email]
> 
> >>
> >> --
> > Sent from my phone
> >
>
>
> -
> To unsubscribe, e-mail: [hidden email]
> 
> For additional commands, e-mail: [hidden email]
> 
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/DISCUSS-3-5-0-alpha-beta-s-on-Central-
> tp5900105p5900156.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://maven.40175.n5.nabble.com/DISCUSS-3-5-0-alpha-beta-s-on-Central-tp5900105p5900196.html
Sent from the Maven Developers mailing list archive at Nabble.com.

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 this edge case would not be a bad idea: 
in fact, I'd expect in a future Maven version that such multiple definition of 
a property on CLI would print a WARNING, because it shows some strange 
situation that people didn't expect

Regards,

Hervé

Le dimanche 26 février 2017, 07:03:05 CET Christian Schulte a écrit :
> Am 02/25/17 um 17:25 schrieb Tibor Digana:
> >>> There are two commits for MNG-6078 part of -alpha-1.
> > 
> > This was caused by system property duplicates in surefire ITs.
> > It is already fixed in a branch SUREFIRE_SYSPROP_DUPLICATES.
> 
> If something works with 3.3.9 but not 3.5.0, we need to fix it in Maven.
> I think this is what Stephen did. No need to "fix" surefire ITs, if they
> were working with 3.3.9 before. 3.5.0 would not be a drop in replacement
> anymore that way.
> 
> Regards,



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

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

2017-02-26 Thread Arnaud Héritier

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 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, appveyor etc. or
> with Jenkins as well..
>
> To give the best availability is to use Central...
>
> I'm not a fan of making a message into Maven alpha/beta saying this is a
> alpha version...(mvn -V will already print that out). That message will
> not prevent one of using it...
> So in the end it's up to the users to decide to use an alpha/beta or
> later upgrade or not...
>
> Kind regards
> Karl Heinz Marbaise
>
> On 25/02/17 22:55, Karl Heinz Marbaise wrote:
> > Hi,
> >
> > based on the started discussion about either to bring 3.5.0-alpha-1 to
> > Central or not I would suggest to discuss in a separate thread and
> > prevent using the VOTE's threads for that (as Stephen already mentioned).
> >
> > Using Central:
> >  o Everybody can use it and make tests on it.
> >
> > Using an other repository:
> >  o Which one?
> >
> > Using only dist area? Or something different?
> >
> > WDY?
> >
> > Based on earlier releases which had been in Central with alpha's:
> >
> >
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22apache-maven%22
> >
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

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