date:20170218

notice: on PrintStream, autoflush does such flush only when newline is appended

see https://docs.oracle.com/javase/7/docs/api/java/io/
PrintStream.html#PrintStream(java.io.OutputStream,%20boolean)

Regards,

Hervé

Le samedi 18 février 2017, 13:45:14 CET Robert Scholte a écrit :
> I've added a unittest, just to be sure.
> Not sure about the price of flushing, but seems expensive to do it after
> every write of a single byte.
> 
> Robert
> 
> On Sat, 18 Feb 2017 08:41:54 +0100,  wrote:
> > Author: tibordigana
> > Date: Sat Feb 18 07:41:54 2017
> > New Revision: 1783494
> > 
> > URL: http://svn.apache.org/viewvc?rev=1783494=rev
> > Log:
> > [MSHARED-617] (FreeBSD) StreamFeeder.java should flush OutputStream
> > 
> > Modified:
> > maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apach
> > e/maven/shared/utils/cli/StreamFeeder.java> 
> > Modified:
> > maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/ma
> > ven/shared/utils/cli/StreamFeeder.java URL:
> > http://svn.apache.org/viewvc/maven/shared/branches/maven-shared-utils-0.9.
> > x/src/main/java/org/apache/maven/shared/utils/cli/StreamFeeder.java?rev=17
> > 83494=1783493=1783494=diff
> > =
> > = ---
> > maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/ma
> > ven/shared/utils/cli/StreamFeeder.java (original)
> > +++
> > maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/ma
> > ven/shared/utils/cli/StreamFeeder.java Sat Feb 18 07:41:54 2017
> > @@ -125,6 +125,7 @@ class StreamFeeder
> > 
> >  if ( !isDisabled() )
> >  {
> >  
> >  os.write( data );
> > 
> > +os.flush();
> > 
> >  }
> >  
> >  }
> >  
> >  }
> 
> -
> 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: Fwd: How to name modules, automatic and otherwise

IMHO, this means that there is the vast majority of "normal" case
then there is life, where exceptionnally everything is mixed:
- publishing a temporary fork (for example to have some local patches)
- really forking or moving

then I'm not sure checking rules on what is inside an artifact while 
publishing in Central is the right thing to do: we don't do it currently 
(checking that package names are consistent with groupId), then I feel we 
should not do it either for module info

it's just a basic convention for normal cases, that will be applied more than 
90% of time: and there will be less than 10% of time where discrepency will 
happen, due to some special cases in code life
As usual

Regards,

Hervé

Le dimanche 19 février 2017, 00:45:29 CET Christian Schulte a écrit :
> Am 02/18/17 um 12:25 schrieb Robert Scholte:
> > The idea from Hervé and Rémi is about having a publish rule in Central if
> > you want to publish a modular jar there which will prevent module name
> > collisions.
> > Because the groupId is already owned by a specific organisation, you could
> > use them as well as "namespace"/prefix of the modular name to ensure that
> > within Central modular names are unique.
> > 
> > However, this collides with the idea from Mark who says that it should be
> > possible to move a modulename from one organisation to another. That
> > should only effect the GA, not the module name.
> 
> Like we did with the resolver. Changed the coordinates but did not
> change package names and class names. So the module name should not
> change as well. This means the coordinates are nothing to consider for
> the module names but package names and class names (the content - not
> the coordinates).
> 
> Regards,



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

Re: Fwd: How to name modules, automatic and otherwise

Am 02/18/17 um 12:25 schrieb Robert Scholte:
> The idea from Hervé and Rémi is about having a publish rule in Central if  
> you want to publish a modular jar there which will prevent module name  
> collisions.
> Because the groupId is already owned by a specific organisation, you could  
> use them as well as "namespace"/prefix of the modular name to ensure that  
> within Central modular names are unique.
> 
> However, this collides with the idea from Mark who says that it should be  
> possible to move a modulename from one organisation to another. That  
> should only effect the GA, not the module name.

Like we did with the resolver. Changed the coordinates but did not
change package names and class names. So the module name should not
change as well. This means the coordinates are nothing to consider for
the module names but package names and class names (the content - not
the coordinates).

Regards,
-- 
Christian



-
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-18 Thread ChristianSchulte

GitHub user ChristianSchulte opened a pull request:

https://github.com/apache/maven-surefire/pull/144

Resource leaks.



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

$ git pull https://github.com/ChristianSchulte/maven-surefire master

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

https://github.com/apache/maven-surefire/pull/144.patch

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

This closes #144


commit 3530cc137cbeb12002212a516bc2d41a769b3274
Author: Christian Schulte 
Date:   2017-02-18T22:37:27Z

o Resource leak in 'RunEntryStatisticsMap'.

commit 9f1ace227eef2d8e9c2bb9dbf66b848f0ffeec9e
Author: Christian Schulte 
Date:   2017-02-18T22:40:38Z

o Resource leak in 'ConsoleOutputFileReporter'.




---
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: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

Am 02/17/17 um 21:48 schrieb Michael Osipov:
> Hi folks,
> 
> Christian Schulte asked me a couple of days ago wether I am able to 
> build Surefire master with Maven master. It was constantly failing for 
> him on his OpenBSD machines. Since I have several real servers with 
> FreeBSD 10.3-STABLE at hand I did run all Surefire ITs and I was able to 
> reproduce it. Our entire test infrastructure wasn't unfortunately!
> 
> @Tibor: correct me if something is wrong or missing!
> 
> After several days of heavy testing, thread dumps and log file analysis 
> with Tibor Digana and various Maven combinations (3.3.9, master, 
> MNG-6169, MNG-6169 + MCLEAN 3.0.0) we figured out that there are several 
> serious bugs in Surefire master, Maven Shared Utils 0.9/3.1.0 and likely 
> Maven Clean Plugin 3.0.0.
> 
> Since crucial parts of Surefire rely on native code in the JVM (forks, 
> streams), our code was not robust enough.
> 
> As of today we have found:
> 
> * Missing flushes in streams caused forked VM to be apparently 
> non-responsive
> * TestNG tests mostly failed due to duplicate contradicting properties 
> passed to forked VMs
> * Uninitialized/too early attributes made daemon threads to kill forked VMs
> * Code or dependency change from MCLEAN 2.6.1 to 3.0.0 cause repeated 
> failures of a handful ITs
> @Karl Heinz: were you able to figure out something here?
> 
> Issues in JIRA are pending...
> 
> Everyone's invited to take a look at the log output as well as the 
> target directory of surefire-integration-tests and contribute:
> http://home.apache.org/~michaelo/maven/surefire/. The filenames should 
> be pretty much self-explanatory.
> 
> My big question is: how can we improve our test infrastructure? Can we 
> raise with INFRA to get at least one FreeBSD and Solaris node for 
> Jenkins? I consider coverage on Windows and Ubuntu way to small, we do 
> not even have a CentOS node. Surefire ITs and Maven ITs are paramount 
> for us, we should treat them as such!
> 
> Michael

Does any of your findings solve the following already? This is what
makes the Jenkins build jobs appear unreliable. It's sending out an
email about a failed job and all you see is something like the following
sporadically. I am having the same issue locally sporadically.

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test
(default-test) on project child2: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The
forked VM terminated without saying properly goodbye. VM crash or
System.exit called ? -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test
(default-test) on project child2: Execution default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test failed: The
forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

>>MNG-6169 + local revert of clean gives:
Not sure about your change (MNG-6169 + local revert of clean), but I know
that
The Clean Plugin 3.0.0 caused folder target/surefire-reports to be suddenly
deleted.
No report files found.

>> Yes but is this failing because of a regression in core or surefire?
Regarding
shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT)
No regression or Maven and Surefire.
Strange isn't it?
The principle of this bug is that the POM in surefire-integration-tests
module has property
5.7
So the IT runs Java process with this property, but the problem is that
certain TestNG tests add the same property in CLI with version 5.10. The
MavenLauncher has ArrayList of these CLI goals. Duplicates are
allowed in ArrayList. So the branch SUREFIRE_SYSPROP_DUPLICATES is hotfix
and overrides old system property instead of duplicating them.
Best would be to remove the aforementioned property in POM and amend 58
ITs. The hotfix was faster to do.

Long explanation, but I would not judge Maven or Surefire regression.



On Sat, Feb 18, 2017 at 6:38 PM, stephenconnolly [via Maven] <
ml-node+s40175n5899153...@n5.nabble.com> wrote:

> MNG-6169 + local revert of clean gives:
>
> Failed tests:
> shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT):
>
> log pattern does not match nTimes(..)
>
>
> testSkippedSurefireReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772BothReportsIT):
>
> Expecting failsafe report file
>
>
> testReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772BothReportsIT):
>
> Expecting failsafe report file
>
>
> testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.
> Surefire772NoSurefireReportsIT):
> Expecting failsafe report file
>
>
> testSkippedSurefireReportGeneration(org.apache.maven.surefire.its.jiras.
> Surefire772NoSurefireReportsIT):
> Expecting failsafe report file
>
>
> testSkipOptionalSurefireReportGeneration(org.apache.maven.
> surefire.its.jiras.Surefire772NoSurefireReportsIT):
> Expecting failsafe report file
>
>
> testReportGeneration(org.apache.maven.surefire.its.jiras.
> Surefire772NoSurefireReportsIT):
> Expecting failsafe report file
>
>
> Tests run: 714, Failures: 7, Errors: 0, Skipped: 133
>
> On 18 February 2017 at 17:36, Stephen Connolly <
> [hidden email] >
> wrote:
>
> > Yes but is this failing because of a regression in core or surefire?
> >
> > On 18 February 2017 at 17:32, Tibor Digana <[hidden email]
> > wrote:
> >
> >> Hi Stephen,
> >>
> >> Both branches should be merged together.
> >> SUREFIRE_SYSPROP_DUPLICATES
> >> SUREFIRE_STDOUT_FLUSH
> >> All tests should pass then.
> >> Cheers
> >> Tibor
> >>
> >> On Sat, Feb 18, 2017 at 6:21 PM, Tibor Digana-2 [via Maven] <
> >> [hidden email] >
> wrote:
> >>
> >> > We had this problem and the branch SUREFIRE_SYSPROP_DUPLICATES should
> >> fix
> >> > it.
> >> >
> >> > On Sat, Feb 18, 2017 at 6:12 PM, Stephen Connolly <
> >> > [hidden email] >
>
> >> > wrote:
> >> >
> >> > > So Maven 3.5.0-SNAPSHOT just has one failure:
> >> > >
> >> > >
> >> > > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 14.835
> >> > sec
> >> > > <<< FAILURE!
> >> > >
> >> > > shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNg
> >> ReportTestIT)
> >> >
> >> > > Time elapsed: 0 sec  <<< FAILURE!
> >> > >
> >> > > java.lang.AssertionError: log pattern does not match nTimes
> >> > >
> >> > > Expected: is <0>
> >> > >
> >> > >  but: was <1>
> >> > >
> >> > > at org.hamcrest.MatcherAssert.ass
> >> ertThat(MatcherAssert.java:20)
> >> > >
> >> > > at
> >> > > org.apache.maven.surefire.its.fixture.OutputValidator.assert
> >> ThatLogLine(
> >> >
> >> > > OutputValidator.java:104)
> >> > >
> >> > > at
> >> > > org.apache.maven.surefire.its.CheckTestNgReportTestIT.should
> >> NotBeVerbose(
> >> >
> >> > > CheckTestNgReportTestIT.java:55)
> >> > >
> >> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> >> Method)
> >> > >
> >> > > at
> >> > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> >> ssorImpl.java:
> >> >
> >> > > 62)
> >> > >
> >> > > at
> >> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> >> > > DelegatingMethodAccessorImpl.java:43)
> >> > >
> >> > > at java.lang.reflect.Method.invoke(Method.java:498)
> >> > >
> >> > > at
> >> > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> >> > > FrameworkMethod.java:50)
> >> > >
> >> > > at
> >> > > org.junit.internal.runners.model.ReflectiveCallable.run(
> >> > > ReflectiveCallable.java:12)
> >> > >
> >> > > at
> >> > > org.junit.runners.model.FrameworkMethod.invokeExplosively(
> >> > > FrameworkMethod.java:47)
> >> > >
> >> > > at
> >> > >

Re: I think we are ready for 3.5.0-alpha-1

Am 02/18/17 um 11:41 schrieb Stephen Connolly:
> We need help testing on Solaris 10/11 if anyone has access to such a system

On a SPARC machine, if possible, please.


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

Re: [ANN] feature freeze Maven core 3.5.0

Am 02/18/17 um 12:25 schrieb Stephen Connolly:
> Bug fixes only. Let's shake down towards the release.

+1

Currently trying to make Jenkins build almost all Maven codebases
automatically daily with Maven master. Setup isn't finished yet, though.



There are plugin IT failures on windows only. That's what I am currently
looking into.

Regards,
-- 
Christian


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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

MNG-6169 + local revert of clean gives:

Failed tests:
shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT):
log pattern does not match nTimes(..)


testSkippedSurefireReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772BothReportsIT):
Expecting failsafe report file


testReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772BothReportsIT):
Expecting failsafe report file


testOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT):
Expecting failsafe report file


testSkippedSurefireReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT):
Expecting failsafe report file


testSkipOptionalSurefireReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT):
Expecting failsafe report file


testReportGeneration(org.apache.maven.surefire.its.jiras.Surefire772NoSurefireReportsIT):
Expecting failsafe report file


Tests run: 714, Failures: 7, Errors: 0, Skipped: 133

On 18 February 2017 at 17:36, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Yes but is this failing because of a regression in core or surefire?
>
> On 18 February 2017 at 17:32, Tibor Digana  wrote:
>
>> Hi Stephen,
>>
>> Both branches should be merged together.
>> SUREFIRE_SYSPROP_DUPLICATES
>> SUREFIRE_STDOUT_FLUSH
>> All tests should pass then.
>> Cheers
>> Tibor
>>
>> On Sat, Feb 18, 2017 at 6:21 PM, Tibor Digana-2 [via Maven] <
>> ml-node+s40175n5899136...@n5.nabble.com> wrote:
>>
>> > We had this problem and the branch SUREFIRE_SYSPROP_DUPLICATES should
>> fix
>> > it.
>> >
>> > On Sat, Feb 18, 2017 at 6:12 PM, Stephen Connolly <
>> > [hidden email] >
>> > wrote:
>> >
>> > > So Maven 3.5.0-SNAPSHOT just has one failure:
>> > >
>> > >
>> > > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.835
>> > sec
>> > > <<< FAILURE!
>> > >
>> > > shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNg
>> ReportTestIT)
>> >
>> > > Time elapsed: 0 sec  <<< FAILURE!
>> > >
>> > > java.lang.AssertionError: log pattern does not match nTimes
>> > >
>> > > Expected: is <0>
>> > >
>> > >  but: was <1>
>> > >
>> > > at org.hamcrest.MatcherAssert.ass
>> ertThat(MatcherAssert.java:20)
>> > >
>> > > at
>> > > org.apache.maven.surefire.its.fixture.OutputValidator.assert
>> ThatLogLine(
>> >
>> > > OutputValidator.java:104)
>> > >
>> > > at
>> > > org.apache.maven.surefire.its.CheckTestNgReportTestIT.should
>> NotBeVerbose(
>> >
>> > > CheckTestNgReportTestIT.java:55)
>> > >
>> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> > >
>> > > at
>> > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:
>> >
>> > > 62)
>> > >
>> > > at
>> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> > > DelegatingMethodAccessorImpl.java:43)
>> > >
>> > > at java.lang.reflect.Method.invoke(Method.java:498)
>> > >
>> > > at
>> > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
>> > > FrameworkMethod.java:50)
>> > >
>> > > at
>> > > org.junit.internal.runners.model.ReflectiveCallable.run(
>> > > ReflectiveCallable.java:12)
>> > >
>> > > at
>> > > org.junit.runners.model.FrameworkMethod.invokeExplosively(
>> > > FrameworkMethod.java:47)
>> > >
>> > > at
>> > > org.junit.internal.runners.statements.InvokeMethod.
>> > > evaluate(InvokeMethod.java:17)
>> > >
>> > > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:
>> 325)
>> >
>> > >
>> > > at
>> > > org.junit.runners.BlockJUnit4ClassRunner.runChild(
>> > > BlockJUnit4ClassRunner.java:78)
>> > >
>> > > at
>> > > org.junit.runners.BlockJUnit4ClassRunner.runChild(
>> > > BlockJUnit4ClassRunner.java:57)
>> > >
>> > > at org.junit.runners.ParentRunner
>> $3.run(ParentRunner.java:290)
>> > >
>> > > at org.junit.runners.ParentRunner
>> $1.schedule(ParentRunner.java:71)
>> >
>> > >
>> > > at org.junit.runners.ParentRunner.runChildren(
>> > > ParentRunner.java:288)
>> > >
>> > > at org.junit.runners.ParentRunner
>> .access$000(ParentRunner.java:58)
>> >
>> > >
>> > > at org.junit.runners.ParentRunner$2.evaluate(
>> > > ParentRunner.java:268)
>> > >
>> > > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>> > >
>> > > at org.junit.runners.Suite.runChild(Suite.java:128)
>> > >
>> > > at org.junit.runners.Suite.runChild(Suite.java:27)
>> > >
>> > > at org.junit.runners.ParentRunner
>> $3.run(ParentRunner.java:290)
>> > >
>> > > at org.junit.runners.ParentRunner
>> $1.schedule(ParentRunner.java:71)
>> >
>> > >
>> > > at org.junit.runners.ParentRunner.runChildren(
>> > > ParentRunner.java:288)
>> > >
>> > > at org.junit.runners.ParentRunner
>> .access$000(ParentRunner.java:58)
>> >
>> > >
>> > > at

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

Yes but is this failing because of a regression in core or surefire?

On 18 February 2017 at 17:32, Tibor Digana  wrote:

> Hi Stephen,
>
> Both branches should be merged together.
> SUREFIRE_SYSPROP_DUPLICATES
> SUREFIRE_STDOUT_FLUSH
> All tests should pass then.
> Cheers
> Tibor
>
> On Sat, Feb 18, 2017 at 6:21 PM, Tibor Digana-2 [via Maven] <
> ml-node+s40175n5899136...@n5.nabble.com> wrote:
>
> > We had this problem and the branch SUREFIRE_SYSPROP_DUPLICATES should fix
> > it.
> >
> > On Sat, Feb 18, 2017 at 6:12 PM, Stephen Connolly <
> > [hidden email] >
> > wrote:
> >
> > > So Maven 3.5.0-SNAPSHOT just has one failure:
> > >
> > >
> > > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.835
> > sec
> > > <<< FAILURE!
> > >
> > > shouldNotBeVerbose(org.apache.maven.surefire.its.
> CheckTestNgReportTestIT)
> >
> > > Time elapsed: 0 sec  <<< FAILURE!
> > >
> > > java.lang.AssertionError: log pattern does not match nTimes
> > >
> > > Expected: is <0>
> > >
> > >  but: was <1>
> > >
> > > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:
> 20)
> > >
> > > at
> > > org.apache.maven.surefire.its.fixture.OutputValidator.
> assertThatLogLine(
> >
> > > OutputValidator.java:104)
> > >
> > > at
> > > org.apache.maven.surefire.its.CheckTestNgReportTestIT.
> shouldNotBeVerbose(
> >
> > > CheckTestNgReportTestIT.java:55)
> > >
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >
> > > at
> > > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:
> >
> > > 62)
> > >
> > > at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > > DelegatingMethodAccessorImpl.java:43)
> > >
> > > at java.lang.reflect.Method.invoke(Method.java:498)
> > >
> > > at
> > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> > > FrameworkMethod.java:50)
> > >
> > > at
> > > org.junit.internal.runners.model.ReflectiveCallable.run(
> > > ReflectiveCallable.java:12)
> > >
> > > at
> > > org.junit.runners.model.FrameworkMethod.invokeExplosively(
> > > FrameworkMethod.java:47)
> > >
> > > at
> > > org.junit.internal.runners.statements.InvokeMethod.
> > > evaluate(InvokeMethod.java:17)
> > >
> > > at org.junit.runners.ParentRunner.runLeaf(
> ParentRunner.java:325)
> >
> > >
> > > at
> > > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> > > BlockJUnit4ClassRunner.java:78)
> > >
> > > at
> > > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> > > BlockJUnit4ClassRunner.java:57)
> > >
> > > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> > >
> > > at org.junit.runners.ParentRunner$1.schedule(
> ParentRunner.java:71)
> >
> > >
> > > at org.junit.runners.ParentRunner.runChildren(
> > > ParentRunner.java:288)
> > >
> > > at org.junit.runners.ParentRunner.access$000(
> ParentRunner.java:58)
> >
> > >
> > > at org.junit.runners.ParentRunner$2.evaluate(
> > > ParentRunner.java:268)
> > >
> > > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> > >
> > > at org.junit.runners.Suite.runChild(Suite.java:128)
> > >
> > > at org.junit.runners.Suite.runChild(Suite.java:27)
> > >
> > > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> > >
> > > at org.junit.runners.ParentRunner$1.schedule(
> ParentRunner.java:71)
> >
> > >
> > > at org.junit.runners.ParentRunner.runChildren(
> > > ParentRunner.java:288)
> > >
> > > at org.junit.runners.ParentRunner.access$000(
> ParentRunner.java:58)
> >
> > >
> > > at org.junit.runners.ParentRunner$2.evaluate(
> > > ParentRunner.java:268)
> > >
> > > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> > >
> > > at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> > >
> > > at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> > >
> > > at
> > > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.
> > > execute(JUnitCoreWrapper.java:62)
> > >
> > > at
> > > org.apache.maven.surefire.junitcore.JUnitCoreProvider.
> > > invoke(JUnitCoreProvider.java:139)
> > >
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >
> > > at
> > > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:
> >
> > > 62)
> > >
> > > at
> > > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > > DelegatingMethodAccessorImpl.java:43)
> > >
> > > at java.lang.reflect.Method.invoke(Method.java:498)
> > >
> > > at
> > > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> > > ReflectionUtils.java:189)
> > >
> > > at
> > > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> > > ProviderFactory.java:165)
> > >
> > > at
> > >

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

Hi Stephen,

Both branches should be merged together.
SUREFIRE_SYSPROP_DUPLICATES
SUREFIRE_STDOUT_FLUSH
All tests should pass then.
Cheers
Tibor

On Sat, Feb 18, 2017 at 6:21 PM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5899136...@n5.nabble.com> wrote:

> We had this problem and the branch SUREFIRE_SYSPROP_DUPLICATES should fix
> it.
>
> On Sat, Feb 18, 2017 at 6:12 PM, Stephen Connolly <
> [hidden email] >
> wrote:
>
> > So Maven 3.5.0-SNAPSHOT just has one failure:
> >
> >
> > Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.835
> sec
> > <<< FAILURE!
> >
> > shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT)
>
> > Time elapsed: 0 sec  <<< FAILURE!
> >
> > java.lang.AssertionError: log pattern does not match nTimes
> >
> > Expected: is <0>
> >
> >  but: was <1>
> >
> > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> >
> > at
> > org.apache.maven.surefire.its.fixture.OutputValidator.assertThatLogLine(
>
> > OutputValidator.java:104)
> >
> > at
> > org.apache.maven.surefire.its.CheckTestNgReportTestIT.shouldNotBeVerbose(
>
> > CheckTestNgReportTestIT.java:55)
> >
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>
> > 62)
> >
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> >
> > at java.lang.reflect.Method.invoke(Method.java:498)
> >
> > at
> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> > FrameworkMethod.java:50)
> >
> > at
> > org.junit.internal.runners.model.ReflectiveCallable.run(
> > ReflectiveCallable.java:12)
> >
> > at
> > org.junit.runners.model.FrameworkMethod.invokeExplosively(
> > FrameworkMethod.java:47)
> >
> > at
> > org.junit.internal.runners.statements.InvokeMethod.
> > evaluate(InvokeMethod.java:17)
> >
> > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>
> >
> > at
> > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> > BlockJUnit4ClassRunner.java:78)
> >
> > at
> > org.junit.runners.BlockJUnit4ClassRunner.runChild(
> > BlockJUnit4ClassRunner.java:57)
> >
> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> >
> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> >
> > at org.junit.runners.ParentRunner.runChildren(
> > ParentRunner.java:288)
> >
> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> >
> > at org.junit.runners.ParentRunner$2.evaluate(
> > ParentRunner.java:268)
> >
> > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> >
> > at org.junit.runners.Suite.runChild(Suite.java:128)
> >
> > at org.junit.runners.Suite.runChild(Suite.java:27)
> >
> > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> >
> > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> >
> > at org.junit.runners.ParentRunner.runChildren(
> > ParentRunner.java:288)
> >
> > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> >
> > at org.junit.runners.ParentRunner$2.evaluate(
> > ParentRunner.java:268)
> >
> > at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> >
> > at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> >
> > at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> >
> > at
> > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.
> > execute(JUnitCoreWrapper.java:62)
> >
> > at
> > org.apache.maven.surefire.junitcore.JUnitCoreProvider.
> > invoke(JUnitCoreProvider.java:139)
> >
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >
> > at
> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>
> > 62)
> >
> > at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> >
> > at java.lang.reflect.Method.invoke(Method.java:498)
> >
> > at
> > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> > ReflectionUtils.java:189)
> >
> > at
> > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> > ProviderFactory.java:165)
> >
> > at
> > org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(
> > ProviderFactory.java:85)
> >
> > at
> > org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.
> > runSuitesInProcess(InPluginVMSurefireStarter.java:80)
> >
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(
> > AbstractSurefireMojo.java:724)
> >
> > at
> > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(
>
> > AbstractSurefireMojo.java:682)
> >
> >

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

We had this problem and the branch SUREFIRE_SYSPROP_DUPLICATES should fix
it.

On Sat, Feb 18, 2017 at 6:12 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> So Maven 3.5.0-SNAPSHOT just has one failure:
>
>
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.835 sec
> <<< FAILURE!
>
> shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT)
> Time elapsed: 0 sec  <<< FAILURE!
>
> java.lang.AssertionError: log pattern does not match nTimes
>
> Expected: is <0>
>
>  but: was <1>
>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
>
> at
> org.apache.maven.surefire.its.fixture.OutputValidator.assertThatLogLine(
> OutputValidator.java:104)
>
> at
> org.apache.maven.surefire.its.CheckTestNgReportTestIT.shouldNotBeVerbose(
> CheckTestNgReportTestIT.java:55)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 62)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:50)
>
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
>
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:47)
>
> at
> org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
>
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:78)
>
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:57)
>
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> at org.junit.runners.ParentRunner.runChildren(
> ParentRunner.java:288)
>
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> at org.junit.runners.ParentRunner$2.evaluate(
> ParentRunner.java:268)
>
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
> at org.junit.runners.Suite.runChild(Suite.java:128)
>
> at org.junit.runners.Suite.runChild(Suite.java:27)
>
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> at org.junit.runners.ParentRunner.runChildren(
> ParentRunner.java:288)
>
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> at org.junit.runners.ParentRunner$2.evaluate(
> ParentRunner.java:268)
>
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
>
> at
> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.
> execute(JUnitCoreWrapper.java:62)
>
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.
> invoke(JUnitCoreProvider.java:139)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 62)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> ReflectionUtils.java:189)
>
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> ProviderFactory.java:165)
>
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(
> ProviderFactory.java:85)
>
> at
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.
> runSuitesInProcess(InPluginVMSurefireStarter.java:80)
>
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(
> AbstractSurefireMojo.java:724)
>
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(
> AbstractSurefireMojo.java:682)
>
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.
> executeAfterPreconditionsChecked(AbstractSurefireMojo.java:648)
>
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.
> execute(AbstractSurefireMojo.java:586)
>
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> DefaultBuildPluginManager.java:134)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:207)
>
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:153)
>
> at
>

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

Same for 3.5.0-SNAPSHOT + MNG-6169 on OS-X

Results :


Failed tests:
shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT):
log pattern does not match nTimes(..)


Tests run: 714, Failures: 1, Errors: 0, Skipped: 133



On 18 February 2017 at 17:12, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> So Maven 3.5.0-SNAPSHOT just has one failure:
>
>
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.835 sec
> <<< FAILURE!
>
> shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT)
> Time elapsed: 0 sec  <<< FAILURE!
>
> java.lang.AssertionError: log pattern does not match nTimes
>
> Expected: is <0>
>
>  but: was <1>
>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
>
> at org.apache.maven.surefire.its.fixture.OutputValidator.
> assertThatLogLine(OutputValidator.java:104)
>
> at org.apache.maven.surefire.its.CheckTestNgReportTestIT.
> shouldNotBeVerbose(CheckTestNgReportTestIT.java:55)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
>
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:50)
>
> at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
>
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:47)
>
> at org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
>
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:78)
>
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:57)
>
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> at org.junit.runners.ParentRunner.runChildren(
> ParentRunner.java:288)
>
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> at org.junit.runners.ParentRunner$2.evaluate(
> ParentRunner.java:268)
>
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
> at org.junit.runners.Suite.runChild(Suite.java:128)
>
> at org.junit.runners.Suite.runChild(Suite.java:27)
>
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>
> at org.junit.runners.ParentRunner.runChildren(
> ParentRunner.java:288)
>
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
> at org.junit.runners.ParentRunner$2.evaluate(
> ParentRunner.java:268)
>
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
>
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.
> execute(JUnitCoreWrapper.java:62)
>
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.
> invoke(JUnitCoreProvider.java:139)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
>
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:498)
>
> at org.apache.maven.surefire.util.ReflectionUtils.
> invokeMethodWithArray(ReflectionUtils.java:189)
>
> at org.apache.maven.surefire.booter.ProviderFactory$
> ProviderProxy.invoke(ProviderFactory.java:165)
>
> at org.apache.maven.surefire.booter.ProviderFactory.
> invokeProvider(ProviderFactory.java:85)
>
> at org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.
> runSuitesInProcess(InPluginVMSurefireStarter.java:80)
>
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.
> executeProvider(AbstractSurefireMojo.java:724)
>
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.
> executeAllProviders(AbstractSurefireMojo.java:682)
>
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.
> executeAfterPreconditionsChecked(AbstractSurefireMojo.java:648)
>
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.
> execute(AbstractSurefireMojo.java:586)
>
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
> DefaultBuildPluginManager.java:134)
>
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(
> MojoExecutor.java:207)
>
> at

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

So Maven 3.5.0-SNAPSHOT just has one failure:


Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 14.835 sec
<<< FAILURE!

shouldNotBeVerbose(org.apache.maven.surefire.its.CheckTestNgReportTestIT)
Time elapsed: 0 sec  <<< FAILURE!

java.lang.AssertionError: log pattern does not match nTimes

Expected: is <0>

 but: was <1>

at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)

at
org.apache.maven.surefire.its.fixture.OutputValidator.assertThatLogLine(OutputValidator.java:104)

at
org.apache.maven.surefire.its.CheckTestNgReportTestIT.shouldNotBeVerbose(CheckTestNgReportTestIT.java:55)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)

at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)

at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)

at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)

at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)

at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

at org.junit.runners.Suite.runChild(Suite.java:128)

at org.junit.runners.Suite.runChild(Suite.java:27)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)

at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

at org.junit.runner.JUnitCore.run(JUnitCore.java:137)

at org.junit.runner.JUnitCore.run(JUnitCore.java:115)

at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:62)

at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:139)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)

at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)

at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)

at
org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:80)

at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:724)

at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:682)

at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:648)

at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:586)

at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)

at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

at

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

I have downloaded Michaels log for Maven 3.3.9 & Surefire 2.19.2-SNAPSHOT
http://home.apache.org/~michaelo/maven/surefire/maven-surefire-extended-patch-maven-3.3.9.tar.gz
and 27 tests failed.


On Sat, Feb 18, 2017 at 4:52 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> So results so far: surefire master branch builds with 3.3.9 but fails with
> 3.5.0-SNAPSHOT when running on macOS Sierra with Oracle Java 1.8.0_121
>
> That is certainly looking like a regression in Maven core
>
> On 18 February 2017 at 10:55, Michael Osipov  wrote:
>
> > For those who would like to reproduce the issues:
> >
> > 1. Build Maven distribution from 3.3.9, master, MNG-6169 and MNG-6169
> with
> > locally modified maven-core/src/main/resources/
> META-INF/plexus/components.xml
> > maven-clean-plugin 2.6.1 => 3.0.0.
> > You should have four distros now.
> > 2. Clone Surefire
> > 3. Run all four versions of Maven against Surefire master:
> > > ~/apache-maven-$version/bin/mvn -B -V clean install
> > -Dinvoker.mergeSettings | tee ~/maven-surefire.log
> > Leave mergeSettings out if you have direct Internet connection
> > 4. Save maven-surefire.log and surefire-integration-tests/target for
> > later analysis
> > 5. Branch off Surefire master and apply branches:
> > origin/SUREFIRE_STDOUT_FLUSH
> > origin/SUREFIRE_SYSPROP_DUPLICATES
> > 6. Repeat step 3
> > 7. Checkout maven-shared-utils-0.9.x from Subversion, install and update
> > maven-surefire/pom.xml with version 0.9.1-SNAPSHOT
> > 8. Repeat 6
> > 7. Compare results of 3, 5, 6, 8 as well as with my maven-surefire.log
> > files
> >
> > note: my logs are based on an already patched version (from mentioned
> > branches) of Surefire master.
> >
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



-- 
Cheers
Tibor

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

>>That is certainly looking like a regression in Maven core
But the principle of the bug on FreeBSD should fail the build with Maven
3.3.9 as well. This I do not understand why it is ok with 3.3.9.

On Sat, Feb 18, 2017 at 4:55 PM, Tibor Digana 
wrote:

> ok, let's try with two surefire branches merged together.
>
> On Sat, Feb 18, 2017 at 4:52 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> So results so far: surefire master branch builds with 3.3.9 but fails with
>> 3.5.0-SNAPSHOT when running on macOS Sierra with Oracle Java 1.8.0_121
>>
>> That is certainly looking like a regression in Maven core
>>
>> On 18 February 2017 at 10:55, Michael Osipov  wrote:
>>
>> > For those who would like to reproduce the issues:
>> >
>> > 1. Build Maven distribution from 3.3.9, master, MNG-6169 and MNG-6169
>> with
>> > locally modified maven-core/src/main/resources/
>> META-INF/plexus/components.xml
>> > maven-clean-plugin 2.6.1 => 3.0.0.
>> > You should have four distros now.
>> > 2. Clone Surefire
>> > 3. Run all four versions of Maven against Surefire master:
>> > > ~/apache-maven-$version/bin/mvn -B -V clean install
>> > -Dinvoker.mergeSettings | tee ~/maven-surefire.log
>> > Leave mergeSettings out if you have direct Internet connection
>> > 4. Save maven-surefire.log and surefire-integration-tests/target for
>> > later analysis
>> > 5. Branch off Surefire master and apply branches:
>> > origin/SUREFIRE_STDOUT_FLUSH
>> > origin/SUREFIRE_SYSPROP_DUPLICATES
>> > 6. Repeat step 3
>> > 7. Checkout maven-shared-utils-0.9.x from Subversion, install and update
>> > maven-surefire/pom.xml with version 0.9.1-SNAPSHOT
>> > 8. Repeat 6
>> > 7. Compare results of 3, 5, 6, 8 as well as with my maven-surefire.log
>> > files
>> >
>> > note: my logs are based on an already patched version (from mentioned
>> > branches) of Surefire master.
>> >
>> >
>> > Michael
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >
>> >
>>
>
>
>
> --
> Cheers
> Tibor
>



-- 
Cheers
Tibor

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

ok, let's try with two surefire branches merged together.

On Sat, Feb 18, 2017 at 4:52 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> So results so far: surefire master branch builds with 3.3.9 but fails with
> 3.5.0-SNAPSHOT when running on macOS Sierra with Oracle Java 1.8.0_121
>
> That is certainly looking like a regression in Maven core
>
> On 18 February 2017 at 10:55, Michael Osipov  wrote:
>
> > For those who would like to reproduce the issues:
> >
> > 1. Build Maven distribution from 3.3.9, master, MNG-6169 and MNG-6169
> with
> > locally modified maven-core/src/main/resources/
> META-INF/plexus/components.xml
> > maven-clean-plugin 2.6.1 => 3.0.0.
> > You should have four distros now.
> > 2. Clone Surefire
> > 3. Run all four versions of Maven against Surefire master:
> > > ~/apache-maven-$version/bin/mvn -B -V clean install
> > -Dinvoker.mergeSettings | tee ~/maven-surefire.log
> > Leave mergeSettings out if you have direct Internet connection
> > 4. Save maven-surefire.log and surefire-integration-tests/target for
> > later analysis
> > 5. Branch off Surefire master and apply branches:
> > origin/SUREFIRE_STDOUT_FLUSH
> > origin/SUREFIRE_SYSPROP_DUPLICATES
> > 6. Repeat step 3
> > 7. Checkout maven-shared-utils-0.9.x from Subversion, install and update
> > maven-surefire/pom.xml with version 0.9.1-SNAPSHOT
> > 8. Repeat 6
> > 7. Compare results of 3, 5, 6, 8 as well as with my maven-surefire.log
> > files
> >
> > note: my logs are based on an already patched version (from mentioned
> > branches) of Surefire master.
> >
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>



-- 
Cheers
Tibor

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

So results so far: surefire master branch builds with 3.3.9 but fails with
3.5.0-SNAPSHOT when running on macOS Sierra with Oracle Java 1.8.0_121

That is certainly looking like a regression in Maven core

On 18 February 2017 at 10:55, Michael Osipov  wrote:

> For those who would like to reproduce the issues:
>
> 1. Build Maven distribution from 3.3.9, master, MNG-6169 and MNG-6169 with
> locally modified maven-core/src/main/resources/META-INF/plexus/components.xml
> maven-clean-plugin 2.6.1 => 3.0.0.
> You should have four distros now.
> 2. Clone Surefire
> 3. Run all four versions of Maven against Surefire master:
> > ~/apache-maven-$version/bin/mvn -B -V clean install
> -Dinvoker.mergeSettings | tee ~/maven-surefire.log
> Leave mergeSettings out if you have direct Internet connection
> 4. Save maven-surefire.log and surefire-integration-tests/target for
> later analysis
> 5. Branch off Surefire master and apply branches:
> origin/SUREFIRE_STDOUT_FLUSH
> origin/SUREFIRE_SYSPROP_DUPLICATES
> 6. Repeat step 3
> 7. Checkout maven-shared-utils-0.9.x from Subversion, install and update
> maven-surefire/pom.xml with version 0.9.1-SNAPSHOT
> 8. Repeat 6
> 7. Compare results of 3, 5, 6, 8 as well as with my maven-surefire.log
> files
>
> note: my logs are based on an already patched version (from mentioned
> branches) of Surefire master.
>
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: svn commit: r1783494 - /maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/maven/shared/utils/cli/StreamFeeder.java


I've added a unittest, just to be sure.
Not sure about the price of flushing, but seems expensive to do it after  
every write of a single byte.


Robert

On Sat, 18 Feb 2017 08:41:54 +0100,  wrote:


Author: tibordigana
Date: Sat Feb 18 07:41:54 2017
New Revision: 1783494

URL: http://svn.apache.org/viewvc?rev=1783494=rev
Log:
[MSHARED-617] (FreeBSD) StreamFeeder.java should flush OutputStream

Modified:

maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/maven/shared/utils/cli/StreamFeeder.java

Modified:  
maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/maven/shared/utils/cli/StreamFeeder.java
URL:  
http://svn.apache.org/viewvc/maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/maven/shared/utils/cli/StreamFeeder.java?rev=1783494=1783493=1783494=diff

==
---  
maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/maven/shared/utils/cli/StreamFeeder.java  
(original)
+++  
maven/shared/branches/maven-shared-utils-0.9.x/src/main/java/org/apache/maven/shared/utils/cli/StreamFeeder.java  
Sat Feb 18 07:41:54 2017

@@ -125,6 +125,7 @@ class StreamFeeder
 if ( !isDisabled() )
 {
 os.write( data );
+os.flush();
 }
 }
 }



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

Re: [ANN] feature freeze Maven core 3.5.0

2017-02-18 Thread Karl Heinz Marbaise


Yes.

On 18/02/17 12:37, Arnaud Héritier wrote:

Yeah !!
Le sam. 18 févr. 2017 à 12:25, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :


Bug fixes only. Let's shake down towards the release.

- Stephen
--
Sent from my phone




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

Re: I think we are ready for 3.5.0-alpha-1

2017-02-18 Thread Karl Heinz Marbaise


Hi,

On 18/02/17 12:19, Hervé BOUTEMY wrote:

the discussion is not about merging some code from a branch to master: it's
about doing an alpha release from master


Based on the current state of JIRA for 3.5.0 (all issues closed).

I say let us start making a alpha-1 candidate...

+1 from me for this..

Kind regards
Karl Heinz Marbaise




then do you have concerns about doing an alpha release from master?

or did I miss something? (which branch?)

Regards,

Hervé

Le samedi 18 février 2017, 11:45:17 CET Robert Scholte a écrit :

For me it is a -1 to merge. It is not a regression compared to 3.3.9, so
that issue is not a blocker for me and can be part of a next release.

Robert

On Sat, 18 Feb 2017 09:29:51 +0100, Tibor Digana

 wrote:

+1: changed previous Vote, I want to see colors in console, but Karl
should
explain to Robert's remark that the change was a workaround. If it is
Multithreading Memory Model problem, we can find better fix together. But
now the contains() method is part of logic and dev will try to see it
reasonable logic not knowing it was a workaround.

On Fri, Feb 17, 2017 at 7:18 PM, Stephen Connolly <

stephen.alan.conno...@gmail.com> wrote:

Would it help yet to cut an alpha and start tracking bugs?

I am starting to be concerned that the collective of volunteers are on a
death march with no end in site... so I am seeking ways to identify an
end
where we can cut 3.5.0 and start on 3.5.1

I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
that users could start testing

On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:

Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:

Is there someone who tried to deploy a "large" artifact ?

I have a bug in 3.5 and not in 3.3.9 but for now no time to dig

The project : https://github.com/jenkinsci/maven-plugin



Downloading:

https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/


maven-plugin/2.16-SNAPSHOT/maven-metadata.xml


Downloaded:

https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/


maven-plugin/2.16-SNAPSHOT/maven-metadata.xml


(929 B at 1.5 kB/s)



Uploading:

https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/


maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi


[INFO] I/O exception (java.net.SocketException) caught when


processing


request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write


failed)


[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
[INFO] I/O exception (java.net.SocketException) caught when


processing


request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write


failed)


[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
[INFO] I/O exception (java.net.SocketException) caught when


processing


request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write


failed)


[INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443


In Wagon 2.12 Apache HttpComponents have been upgraded:

diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
index 1995fb7..e29dd55 100644
--- a/wagon-providers/pom.xml
+++ b/wagon-providers/pom.xml
@@ -23,7 +23,7 @@ under the License.

   

 org.apache.maven.wagon
 wagon

-2.10
+2.12

 ../pom.xml

   

@@ -50,12 +50,12 @@ under the License.

   

 org.apache.httpcomponents
 httpclient

-4.3.5
+4.5.2

   
   

 org.apache.httpcomponents
 httpcore

-4.3.2
+4.4.4

   
   

 org.apache.sshd


Additionally, the log dependencies where incorrectly configured which
has been corrected in another ticket.

Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
file, we can easily add a HugeFileUploadTest.

Looking at the log messages issued by the HttpComponents, you have a
network issue. Somewhere between you and the Artifactory instance the
connection has been terminated (broken pipe).

Can you repeat this issue realiably?

Michael



-
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

Re: maven-surefire git commit: SUREFIRE_SYSPROP_DUPLICATES

yes, Jira will be created for these branches, no problem, but let's see
what the future logs bring.

On Sat, Feb 18, 2017 at 12:51 PM, Tibor Digana-2 [via Maven] <
ml-node+s40175n5899063...@n5.nabble.com> wrote:

> The build processes use to take from 45min to 2:21h.
>
> On Sat, Feb 18, 2017 at 12:47 PM, Tibor Digana <[hidden email]
> >
> wrote:
>
> > I am waiting for Michael's "go on".
> > There are 58 TestNG ITs and this is not nice fix, however it is god but
> > the rootcause is that surefire-integration-tests POM has testng default
> > version 5.7 and that is the roortcause of system prop duplicates. I need
> to
> > find someone who will update 58 tests after we and Michael says that the
> > build is passed.
> > Let's see what Stephan's build on Mac says.
> > Fixing 58 test can be done later, does not block Maven.
> >
> >
> > On Sat, Feb 18, 2017 at 12:25 PM, Hervé BOUTEMY <[hidden email]
> >
> > wrote:
> >
> >> IIUC, this one is a good enhancement to integrate, since it makes
> >> Surefire more
> >> reliable (not relying on the way multiple "-Dmyprop=" is handled)
> >>
> >> Then there should just be a Jira issue created, and this fix integrated
> to
> >> Surefire master without waiting, isn't it?
> >>
> >> Or do you fear that this change can have unexpected impact?
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le jeudi 16 février 2017, 17:42:07 CET [hidden email]
>  a écrit :
> >> > Repository: maven-surefire
> >> > Updated Branches:
> >> >   refs/heads/SUREFIRE_SYSPROP_DUPLICATES [created] ef5b0f460
> >> >
> >> >
> >> > SUREFIRE_SYSPROP_DUPLICATES
> >> >
> >> >
> >> > Project: http://git-wip-us.apache.org/repos/asf/maven-surefire/repo
> >> > Commit:
> >> > http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/ef5b0f46
> >> Tree:
> >> > http://git-wip-us.apache.org/repos/asf/maven-surefire/tree/ef5b0f46
> >> Diff:
> >> > http://git-wip-us.apache.org/repos/asf/maven-surefire/diff/ef5b0f46
> >> >
> >> > Branch: refs/heads/SUREFIRE_SYSPROP_DUPLICATES
> >> > Commit: ef5b0f460021ad6f827d75cde38f888f37a54415
> >> > Parents: 179abbf
> >> > Author: Tibor17 <[hidden email]
> >
> >> > Authored: Thu Feb 16 18:40:45 2017 +0100
> >> > Committer: Tibor17 <[hidden email]
> >
> >> > Committed: Thu Feb 16 18:40:45 2017 +0100
> >> >
> >> > --
>
> >> >  .../surefire/its/fixture/MavenLauncher.java | 45
> >> ---
> >> >  .../surefire/its/fixture/MavenLauncherTest.java | 47
> >> 
> >> >  .../surefire/its/fixture/SurefireLauncher.java  |  6 +--
> >> >  3 files changed, 88 insertions(+), 10 deletions(-)
> >> > --
>
> >> >
> >> >
> >> > http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/e
> >> f5b0f46/surefire
> >> > -integration-tests/src/test/java/org/apache/maven/surefire/
> >> its/fixture/Maven
> >> > Launcher.java
> >> > --
>
> >> diff
> >> > --git
> >> > a/surefire-integration-tests/src/test/java/org/apache/maven/
> >> surefire/its/fi
> >> > xture/MavenLauncher.java
> >> > b/surefire-integration-tests/src/test/java/org/apache/maven/
> >> surefire/its/fi
> >> > xture/MavenLauncher.java index 1198fcb..0945068 100755
> >> > ---
> >> > a/surefire-integration-tests/src/test/java/org/apache/maven/
> >> surefire/its/fi
> >> > xture/MavenLauncher.java +++
> >> > b/surefire-integration-tests/src/test/java/org/apache/maven/
> >> surefire/its/fi
> >> > xture/MavenLauncher.java @@ -19,18 +19,22 @@ package
> >> > org.apache.maven.surefire.its.fixture; * under the License.
> >> >   */
> >> >
> >> > +import org.apache.commons.lang.text.StrSubstitutor;
> >> > +import org.apache.maven.it.VerificationException;
> >> > +import org.apache.maven.it.Verifier;
> >> > +import org.apache.maven.it.util.ResourceExtractor;
> >> > +import org.apache.maven.shared.utils.io.FileUtils;
> >> > +
> >> >  import java.io.File;
> >> >  import java.io.IOException;
> >> >  import java.net.URL;
> >> >  import java.util.ArrayList;
> >> >  import java.util.HashMap;
> >> >  import java.util.List;
> >> > +import java.util.ListIterator;
> >> >  import java.util.Map;
> >> > -import org.apache.commons.lang.text.StrSubstitutor;
> >> > -import org.apache.maven.it.VerificationException;
> >> > -import org.apache.maven.it.Verifier;
> >> > -import org.apache.maven.it.util.ResourceExtractor;
> >> > -import org.apache.maven.shared.utils.io.FileUtils;
> >> > +
> >> > +import static java.util.Collections.unmodifiableList;
> >> >
> >> >  /**
> >> >   * Encapsulate all needed features to start a maven run
> >> > @@ -203,13 +207,13 @@ public class MavenLauncher
> >> >
> >> >  public

Re: Fwd: How to name modules, automatic and otherwise

yes, that's it
(eventually without even checking that rule automatically when publishing into 
central: just making an explicit convention to avoid stupid choice of module 
prefix that is different from groupId but another DNS entry one may own)

Regards,

Hervé

Le samedi 18 février 2017, 12:25:40 CET Robert Scholte a écrit :
> The idea from Hervé and Rémi is about having a publish rule in Central if
> you want to publish a modular jar there which will prevent module name
> collisions.
> Because the groupId is already owned by a specific organisation, you could
> use them as well as "namespace"/prefix of the modular name to ensure that
> within Central modular names are unique.
> 
> However, this collides with the idea from Mark who says that it should be
> possible to move a modulename from one organisation to another. That
> should only effect the GA, not the module name.
> 
> So to be clear, Hervé and Rémi are *not* talking about automodules and how
> they should get their name, but only about named modules.
> 
> Robert
> 
> On Fri, 17 Feb 2017 15:01:46 +0100, Brian Fox  wrote:
> > Hervé: I feel like I don't completely understand the proposal, but I feel
> > like we can achieve your intent using the Module-Name simply by
> > defaulting
> > it to g:a and building up a good base of new stuff going into Central
> > such
> > that when people start using jigsaw, there is a good pattern in place and
> > we've hopefully avoided conflicts.
> > 
> > Am I mis-understanding your proposal?
> > 
> > On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY 
> > 
> > wrote:
> >> tuesday, I was at a Jigsaw presentation from Remi Forax in France, where
> >> the
> >> fact that nothing was taken into consideration looked something that was
> >> happenning (and the recent publication shows that it has happened now)
> >> 
> >> Then Remi and I discussed and looked for ideas on what lighter proposal
> >> to
> >> do
> >> for the namespace concern when sharing modules publicly
> >> 
> >> And I proposed a simplified idea that looked promising when we
> >> challenged
> >> 
> >> it:
> >> for modules that are to be shared on Maven Central,
> >> handwritten full module name should *start with groupId*
> >> 
> >> applied to the example for Hibernate, this would just say: Hibernate
> >> project
> >> owns "org.hibernate" module namespace on [Maven] Central since they own
> >> org.hibernate groupId
> >> 
> >> Notice: automodules won't give same module names. Automodules are just
> >> transient automagic values for temporary local work, not for public
> >> shared
> >> work
> >> 
> >> Notice 2: whatever does not go to [Maven] Central has just other
> >> conventions.
> >> Knowing the impact of existing [Maven] Central content, people doing
> >> their
> >> local convention will probably "naturally" think at:
> >> - immediate compatibility, to be able to consume public artifacts
> >> - future compatibility, to be able to later publish a private artifact
> >> that
> >> may be later shared as public artifact
> >> 
> >> 
> >> I started to share this idea (which is not far from initial proposal:
> >> just
> >> not
> >> about automodule names and not using artifactId)  yesterday with Robert:
> >> the
> >> discussion just started, nobody had time yet to write the proposal down
> >> and
> >> share it with a wider audience
> >> 
> >> 
> >> WDYT?
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> >> > And it looks like they are saying .. just add the groupId (or similar
> >> > namespace) to the modulename. A bit like some artifact repeat the
> >> 
> >> groupId
> >> 
> >> > in the artifactId to be specific... seems like a wasted opportunity to
> >> > define a good usage pattern. The idea of actually supporting same
> >> 
> >> module
> >> 
> >> > names for different forks or the same thing is touted as an advantage.
> >> > Anybody that ever had to debug something like this will know its not
> >> 
> >> an
> >> 
> >> > advantage at all .. just simply path to troubleshooting nightmares.
> >> > 
> >> > I expected as much but I am still disappointed and see lots of trouble
> >> 
> >> with
> >> 
> >> > this in the future. Maybe it would be good if all Apache project and
> >> 
> >> others
> >> 
> >> > that are going to publish modules start with using the full namespace
> >> 
> >> in
> >> 
> >> > the module name. Problem is of course that the examples I saw so far
> >> 
> >> all
> >> do
> >> 
> >> > NOT do that so we will end up with a mess anyway..
> >> > 
> >> > Manfred
> >> > 
> >> > Brian Fox wrote on 2017-02-16 10:42:
> >> > > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko
> >> 
> >> 
> >> 
> >> wrote:
> >> > >> Can't we just block auto-named modules from the build? We control
> >> > >> dependencies and should be able to look inside and barf if we don't
> >> 
> >> like
> >> 
> >> > >> anything, no?
> >> > > 
> >> > > Yes but this

Re: maven-surefire git commit: SUREFIRE_SYSPROP_DUPLICATES

The build processes use to take from 45min to 2:21h.

On Sat, Feb 18, 2017 at 12:47 PM, Tibor Digana 
wrote:

> I am waiting for Michael's "go on".
> There are 58 TestNG ITs and this is not nice fix, however it is god but
> the rootcause is that surefire-integration-tests POM has testng default
> version 5.7 and that is the roortcause of system prop duplicates. I need to
> find someone who will update 58 tests after we and Michael says that the
> build is passed.
> Let's see what Stephan's build on Mac says.
> Fixing 58 test can be done later, does not block Maven.
>
>
> On Sat, Feb 18, 2017 at 12:25 PM, Hervé BOUTEMY 
> wrote:
>
>> IIUC, this one is a good enhancement to integrate, since it makes
>> Surefire more
>> reliable (not relying on the way multiple "-Dmyprop=" is handled)
>>
>> Then there should just be a Jira issue created, and this fix integrated to
>> Surefire master without waiting, isn't it?
>>
>> Or do you fear that this change can have unexpected impact?
>>
>> Regards,
>>
>> Hervé
>>
>> Le jeudi 16 février 2017, 17:42:07 CET tibordig...@apache.org a écrit :
>> > Repository: maven-surefire
>> > Updated Branches:
>> >   refs/heads/SUREFIRE_SYSPROP_DUPLICATES [created] ef5b0f460
>> >
>> >
>> > SUREFIRE_SYSPROP_DUPLICATES
>> >
>> >
>> > Project: http://git-wip-us.apache.org/repos/asf/maven-surefire/repo
>> > Commit:
>> > http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/ef5b0f46
>> Tree:
>> > http://git-wip-us.apache.org/repos/asf/maven-surefire/tree/ef5b0f46
>> Diff:
>> > http://git-wip-us.apache.org/repos/asf/maven-surefire/diff/ef5b0f46
>> >
>> > Branch: refs/heads/SUREFIRE_SYSPROP_DUPLICATES
>> > Commit: ef5b0f460021ad6f827d75cde38f888f37a54415
>> > Parents: 179abbf
>> > Author: Tibor17 
>> > Authored: Thu Feb 16 18:40:45 2017 +0100
>> > Committer: Tibor17 
>> > Committed: Thu Feb 16 18:40:45 2017 +0100
>> >
>> > --
>> >  .../surefire/its/fixture/MavenLauncher.java | 45
>> ---
>> >  .../surefire/its/fixture/MavenLauncherTest.java | 47
>> 
>> >  .../surefire/its/fixture/SurefireLauncher.java  |  6 +--
>> >  3 files changed, 88 insertions(+), 10 deletions(-)
>> > --
>> >
>> >
>> > http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/e
>> f5b0f46/surefire
>> > -integration-tests/src/test/java/org/apache/maven/surefire/
>> its/fixture/Maven
>> > Launcher.java
>> > --
>> diff
>> > --git
>> > a/surefire-integration-tests/src/test/java/org/apache/maven/
>> surefire/its/fi
>> > xture/MavenLauncher.java
>> > b/surefire-integration-tests/src/test/java/org/apache/maven/
>> surefire/its/fi
>> > xture/MavenLauncher.java index 1198fcb..0945068 100755
>> > ---
>> > a/surefire-integration-tests/src/test/java/org/apache/maven/
>> surefire/its/fi
>> > xture/MavenLauncher.java +++
>> > b/surefire-integration-tests/src/test/java/org/apache/maven/
>> surefire/its/fi
>> > xture/MavenLauncher.java @@ -19,18 +19,22 @@ package
>> > org.apache.maven.surefire.its.fixture; * under the License.
>> >   */
>> >
>> > +import org.apache.commons.lang.text.StrSubstitutor;
>> > +import org.apache.maven.it.VerificationException;
>> > +import org.apache.maven.it.Verifier;
>> > +import org.apache.maven.it.util.ResourceExtractor;
>> > +import org.apache.maven.shared.utils.io.FileUtils;
>> > +
>> >  import java.io.File;
>> >  import java.io.IOException;
>> >  import java.net.URL;
>> >  import java.util.ArrayList;
>> >  import java.util.HashMap;
>> >  import java.util.List;
>> > +import java.util.ListIterator;
>> >  import java.util.Map;
>> > -import org.apache.commons.lang.text.StrSubstitutor;
>> > -import org.apache.maven.it.VerificationException;
>> > -import org.apache.maven.it.Verifier;
>> > -import org.apache.maven.it.util.ResourceExtractor;
>> > -import org.apache.maven.shared.utils.io.FileUtils;
>> > +
>> > +import static java.util.Collections.unmodifiableList;
>> >
>> >  /**
>> >   * Encapsulate all needed features to start a maven run
>> > @@ -203,13 +207,13 @@ public class MavenLauncher
>> >
>> >  public MavenLauncher skipClean()
>> >  {
>> > -goals.add( "-Dclean.skip=true" );
>> > +writeGoal( "-Dclean.skip=true" );
>> >  return this;
>> >  }
>> >
>> >  public MavenLauncher addGoal( String goal )
>> >  {
>> > -goals.add( goal );
>> > +writeGoal( goal );
>> >  return this;
>> >  }
>> >
>> > @@ -223,6 +227,33 @@ public class MavenLauncher
>> >  return conditionalExec( "test" );
>> >  }
>> >
>> > +List getGoals()
>> > +{
>> > +return unmodifiableList( goals );
>> > +}
>> > +
>> > +private void writeGoal( String newGoal )
>> > +{
>> > +if ( newGoal != null &&

Re: maven-surefire git commit: SUREFIRE_SYSPROP_DUPLICATES

I am waiting for Michael's "go on".
There are 58 TestNG ITs and this is not nice fix, however it is god but the
rootcause is that surefire-integration-tests POM has testng default version
5.7 and that is the roortcause of system prop duplicates. I need to find
someone who will update 58 tests after we and Michael says that the build
is passed.
Let's see what Stephan's build on Mac says.
Fixing 58 test can be done later, does not block Maven.


On Sat, Feb 18, 2017 at 12:25 PM, Hervé BOUTEMY 
wrote:

> IIUC, this one is a good enhancement to integrate, since it makes Surefire
> more
> reliable (not relying on the way multiple "-Dmyprop=" is handled)
>
> Then there should just be a Jira issue created, and this fix integrated to
> Surefire master without waiting, isn't it?
>
> Or do you fear that this change can have unexpected impact?
>
> Regards,
>
> Hervé
>
> Le jeudi 16 février 2017, 17:42:07 CET tibordig...@apache.org a écrit :
> > Repository: maven-surefire
> > Updated Branches:
> >   refs/heads/SUREFIRE_SYSPROP_DUPLICATES [created] ef5b0f460
> >
> >
> > SUREFIRE_SYSPROP_DUPLICATES
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/maven-surefire/repo
> > Commit:
> > http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/ef5b0f46
> Tree:
> > http://git-wip-us.apache.org/repos/asf/maven-surefire/tree/ef5b0f46
> Diff:
> > http://git-wip-us.apache.org/repos/asf/maven-surefire/diff/ef5b0f46
> >
> > Branch: refs/heads/SUREFIRE_SYSPROP_DUPLICATES
> > Commit: ef5b0f460021ad6f827d75cde38f888f37a54415
> > Parents: 179abbf
> > Author: Tibor17 
> > Authored: Thu Feb 16 18:40:45 2017 +0100
> > Committer: Tibor17 
> > Committed: Thu Feb 16 18:40:45 2017 +0100
> >
> > --
> >  .../surefire/its/fixture/MavenLauncher.java | 45
> ---
> >  .../surefire/its/fixture/MavenLauncherTest.java | 47
> 
> >  .../surefire/its/fixture/SurefireLauncher.java  |  6 +--
> >  3 files changed, 88 insertions(+), 10 deletions(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/
> ef5b0f46/surefire
> > -integration-tests/src/test/java/org/apache/maven/
> surefire/its/fixture/Maven
> > Launcher.java
> > --
> diff
> > --git
> > a/surefire-integration-tests/src/test/java/org/apache/
> maven/surefire/its/fi
> > xture/MavenLauncher.java
> > b/surefire-integration-tests/src/test/java/org/apache/
> maven/surefire/its/fi
> > xture/MavenLauncher.java index 1198fcb..0945068 100755
> > ---
> > a/surefire-integration-tests/src/test/java/org/apache/
> maven/surefire/its/fi
> > xture/MavenLauncher.java +++
> > b/surefire-integration-tests/src/test/java/org/apache/
> maven/surefire/its/fi
> > xture/MavenLauncher.java @@ -19,18 +19,22 @@ package
> > org.apache.maven.surefire.its.fixture; * under the License.
> >   */
> >
> > +import org.apache.commons.lang.text.StrSubstitutor;
> > +import org.apache.maven.it.VerificationException;
> > +import org.apache.maven.it.Verifier;
> > +import org.apache.maven.it.util.ResourceExtractor;
> > +import org.apache.maven.shared.utils.io.FileUtils;
> > +
> >  import java.io.File;
> >  import java.io.IOException;
> >  import java.net.URL;
> >  import java.util.ArrayList;
> >  import java.util.HashMap;
> >  import java.util.List;
> > +import java.util.ListIterator;
> >  import java.util.Map;
> > -import org.apache.commons.lang.text.StrSubstitutor;
> > -import org.apache.maven.it.VerificationException;
> > -import org.apache.maven.it.Verifier;
> > -import org.apache.maven.it.util.ResourceExtractor;
> > -import org.apache.maven.shared.utils.io.FileUtils;
> > +
> > +import static java.util.Collections.unmodifiableList;
> >
> >  /**
> >   * Encapsulate all needed features to start a maven run
> > @@ -203,13 +207,13 @@ public class MavenLauncher
> >
> >  public MavenLauncher skipClean()
> >  {
> > -goals.add( "-Dclean.skip=true" );
> > +writeGoal( "-Dclean.skip=true" );
> >  return this;
> >  }
> >
> >  public MavenLauncher addGoal( String goal )
> >  {
> > -goals.add( goal );
> > +writeGoal( goal );
> >  return this;
> >  }
> >
> > @@ -223,6 +227,33 @@ public class MavenLauncher
> >  return conditionalExec( "test" );
> >  }
> >
> > +List getGoals()
> > +{
> > +return unmodifiableList( goals );
> > +}
> > +
> > +private void writeGoal( String newGoal )
> > +{
> > +if ( newGoal != null && newGoal.startsWith( "-D" ) )
> > +{
> > +final String sysPropKey =
> > +newGoal.contains( "=" ) ? newGoal.substring( 0,
> > newGoal.indexOf( '=' ) ) : newGoal; +
> > +final String sysPropStarter = sysPropKey + "=";
> > +
> > +

Re: Fwd: How to name modules, automatic and otherwise


On Thu, 16 Feb 2017 19:11:33 +0100, Brian Fox  wrote:


I generally agree the concerns were mostly ignored. Specifically the
dangers in not carefully approaching and setting best practices in the
names, thereby willfully ignoring what happened with NPM.



It doesn't take away the issue that you can still refer to automodules and  
that their name can/will change in the future.


I think we should introduce 2 new packaging types:
- modlib, which does not allow references to automodules
- modapp, which allows references to automodules, but will never be  
installed or deployed.


In fact, modapp matches one of my ideas for POM5 where GA are not always  
required anymore, e.g. if they are not distributed as dependency.


The inclusion of the Module-Name metadata is frankly, more than I  
expected

we would get. I think this does give us something to work with, first by
making that defaulted by the Maven plugins and later by enforcing in the
repo as appropriate. Using this correctly could help solve some of my
initial concerns that we weren't appropriately leveraging the
default-effect.


Hmm, not sure about the default behavior. I think developers should choose  
their name with care, just as they should choose their groupId and  
artifactId with care.


The Module-Name will make it possible to prepare your project as modular  
jar. This also implies that in the module-info you must specify *every*  
requirement. If only one jar is not yet a named module (either by  
Module-Name or by module-info), you must omit the module-info.java; that's  
a choice, makes our lives a bit easier :)

Just have to be very clear about it towards the community.

Robert



PS: those of you who aren't sure what this was all about, see here:
http://www.sonatype.org/nexus/2017/01/23/advice-for-jigsaw-regarding-auto-modules/

On Thu, Feb 16, 2017 at 12:26 PM, Manfred Moser  


wrote:


I just read it all .. sigh. Looks like our concerns got ignored to me

Manfred

Robert Scholte wrote on 2017-02-16 09:23:

> FYI,
>
> Robert
>
> --- Forwarded message ---
> From: mark.reinh...@oracle.com
> To: jpms-spec-expe...@openjdk.java.net
> Cc:
> Subject: How to name modules, automatic and otherwise
> Date: Thu, 16 Feb 2017 17:48:27 +0100
>
> This note is in reply to the concerns about automatic modules raised  
by

> Robert Scholte and Brian Fox [1], and by Stephen Colebourne and others
> [2].  I've collected my conclusions here rather than in separate  
messages

> because there are several distinct yet intertwined issues.
>
> Summary:
>
>- Module names should not include Maven group identifiers, because
>  modules are more abstract than the artifacts that define them.
>
>- Module names should use the reverse-domain-name-prefix convention
>  or, preferably, the project-name-prefix convention.
>
>- We should not abandon automatic modules, since they are a key  
tool

>  for migration and adoption.
>
>- We can address the problems of automatic modules with two fairly
>  minor technical enhancements.
>
> If any of these points strikes you as controversial, please read on!
>
>* * *
>
> Module names should not include Maven group identifiers, as Robert
> Scholte and Brian Fox suggest [1], even for modules declared  
explicitly
> in `module-info.java` files.  Modules in JPMS are a construct of the  
Java

> programming language, implemented in both the compiler and the virtual
> machine.  As such, they are more abstract entities than the artifacts
> that define them.  This distinction is useful, both conceptually and
> practically, hence module names should remain more abstract.
>
> This distinction is useful conceptually because it makes it easier, as
> we read source code, to think clearly about the nature of a module.   
We
> can reason about a module's dependences, exports, services, and so  
forth

> without cluttering our minds with the details of group identifiers and
> version constraints.  Today, e.g., we can write, and read:
>
>  module foo.data {
>  exports com.bar.foo.data;
>  requires hibernate.core;
>  requires hibernate.jcache;
>  requires hibernate.validator;
>  }
>
> If we were to extend the syntax of module names to include group
> identifiers, and encourage people to use them, then we'd be faced with
> something much more verbose:
>
>  module com.bar:foo.data {
>  exports com.bar.foo.data;
>  requires org.hibernate:hibernate.core;
>  requires org.hibernate:hibernate.jcache;
>  requires org.hibernate:hibernate.validator;
>  }
>
> Group identifiers make perfect sense in the context of a build system
> such as Maven, where they bring necessary structure to the names of  
the

> millions of artifacts available across different repositories.  Such
> structure is superfluous and distracting in the context of a module
> system, where

Re: [ANN] feature freeze Maven core 3.5.0

2017-02-18 Thread Arnaud Héritier

Yeah !!
Le sam. 18 févr. 2017 à 12:25, Stephen Connolly <
stephen.alan.conno...@gmail.com> a écrit :

> Bug fixes only. Let's shake down towards the release.
>
> - Stephen
> --
> Sent from my phone
>
-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Fwd: How to name modules, automatic and otherwise

The idea from Hervé and Rémi is about having a publish rule in Central if  
you want to publish a modular jar there which will prevent module name  
collisions.
Because the groupId is already owned by a specific organisation, you could  
use them as well as "namespace"/prefix of the modular name to ensure that  
within Central modular names are unique.


However, this collides with the idea from Mark who says that it should be  
possible to move a modulename from one organisation to another. That  
should only effect the GA, not the module name.


So to be clear, Hervé and Rémi are *not* talking about automodules and how  
they should get their name, but only about named modules.


Robert

On Fri, 17 Feb 2017 15:01:46 +0100, Brian Fox  wrote:


Hervé: I feel like I don't completely understand the proposal, but I feel
like we can achieve your intent using the Module-Name simply by  
defaulting
it to g:a and building up a good base of new stuff going into Central  
such

that when people start using jigsaw, there is a good pattern in place and
we've hopefully avoided conflicts.

Am I mis-understanding your proposal?

On Thu, Feb 16, 2017 at 8:51 PM, Hervé BOUTEMY 
wrote:


tuesday, I was at a Jigsaw presentation from Remi Forax in France, where
the
fact that nothing was taken into consideration looked something that was
happenning (and the recent publication shows that it has happened now)

Then Remi and I discussed and looked for ideas on what lighter proposal  
to

do
for the namespace concern when sharing modules publicly

And I proposed a simplified idea that looked promising when we  
challenged

it:
for modules that are to be shared on Maven Central,
handwritten full module name should *start with groupId*


applied to the example for Hibernate, this would just say: Hibernate
project
owns "org.hibernate" module namespace on [Maven] Central since they own
org.hibernate groupId

Notice: automodules won't give same module names. Automodules are just
transient automagic values for temporary local work, not for public  
shared

work

Notice 2: whatever does not go to [Maven] Central has just other
conventions.
Knowing the impact of existing [Maven] Central content, people doing  
their

local convention will probably "naturally" think at:
- immediate compatibility, to be able to consume public artifacts
- future compatibility, to be able to later publish a private artifact  
that

may be later shared as public artifact


I started to share this idea (which is not far from initial proposal:  
just

not
about automodule names and not using artifactId)  yesterday with Robert:
the
discussion just started, nobody had time yet to write the proposal down  
and

share it with a wider audience


WDYT?

Regards,

Hervé

Le jeudi 16 février 2017, 19:56:41 CET Manfred Moser a écrit :
> And it looks like they are saying .. just add the groupId (or similar
> namespace) to the modulename. A bit like some artifact repeat the  
groupId

> in the artifactId to be specific... seems like a wasted opportunity to
> define a good usage pattern. The idea of actually supporting same  
module

> names for different forks or the same thing is touted as an advantage.
> Anybody that ever had to debug something like this will know its not  
an

> advantage at all .. just simply path to troubleshooting nightmares.
>
> I expected as much but I am still disappointed and see lots of trouble
with
> this in the future. Maybe it would be good if all Apache project and
others
> that are going to publish modules start with using the full namespace  
in
> the module name. Problem is of course that the examples I saw so far  
all

do
> NOT do that so we will end up with a mess anyway..
>
> Manfred
>
> Brian Fox wrote on 2017-02-16 10:42:
> > On Thu, Feb 16, 2017 at 1:38 PM, Igor Fedorenko  


wrote:
> >> Can't we just block auto-named modules from the build? We control
> >> dependencies and should be able to look inside and barf if we don't
like
> >> anything, no?
> >
> > Yes but this only applies to things that are modularized. The bigger
issue
> > is all the existing stuff that would be used as automodules...first
they
> > are already out there and second, there's nothing to see and block.
> >
> >> I realize this does not set good defaults for non-maven projects,  
so
> >> there will be some friction there, but hopefully maven userbase is  
big
> >> enough to create sufficient pressure for non-maven projects to  
provide

> >> explicit module names.
> >
> > That's exactly my point in originally suggesting to leverage the  
g:a by

> > default, but we can do exactly the same thing by injecting the
Module-Name
> > asap to build up the right practices before jigsaw takes off.
> >
> >> --
> >> Regards,
> >> Igor
> >>
> >> On Thu, Feb 16, 2017, at 01:11 PM, Brian Fox wrote:
> >> > I generally agree the concerns were mostly ignored. Specifically  
the
> >> > dangers in not

[ANN] feature freeze Maven core 3.5.0

Bug fixes only. Let's shake down towards the release.

- Stephen
-- 
Sent from my phone

Re: maven-surefire git commit: SUREFIRE_SYSPROP_DUPLICATES

IIUC, this one is a good enhancement to integrate, since it makes Surefire more 
reliable (not relying on the way multiple "-Dmyprop=" is handled)

Then there should just be a Jira issue created, and this fix integrated to 
Surefire master without waiting, isn't it?

Or do you fear that this change can have unexpected impact?

Regards,

Hervé

Le jeudi 16 février 2017, 17:42:07 CET tibordig...@apache.org a écrit :
> Repository: maven-surefire
> Updated Branches:
>   refs/heads/SUREFIRE_SYSPROP_DUPLICATES [created] ef5b0f460
> 
> 
> SUREFIRE_SYSPROP_DUPLICATES
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/maven-surefire/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/ef5b0f46 Tree:
> http://git-wip-us.apache.org/repos/asf/maven-surefire/tree/ef5b0f46 Diff:
> http://git-wip-us.apache.org/repos/asf/maven-surefire/diff/ef5b0f46
> 
> Branch: refs/heads/SUREFIRE_SYSPROP_DUPLICATES
> Commit: ef5b0f460021ad6f827d75cde38f888f37a54415
> Parents: 179abbf
> Author: Tibor17 
> Authored: Thu Feb 16 18:40:45 2017 +0100
> Committer: Tibor17 
> Committed: Thu Feb 16 18:40:45 2017 +0100
> 
> --
>  .../surefire/its/fixture/MavenLauncher.java | 45 ---
>  .../surefire/its/fixture/MavenLauncherTest.java | 47 
>  .../surefire/its/fixture/SurefireLauncher.java  |  6 +--
>  3 files changed, 88 insertions(+), 10 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/ef5b0f46/surefire
> -integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/Maven
> Launcher.java
> -- diff
> --git
> a/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fi
> xture/MavenLauncher.java
> b/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fi
> xture/MavenLauncher.java index 1198fcb..0945068 100755
> ---
> a/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fi
> xture/MavenLauncher.java +++
> b/surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fi
> xture/MavenLauncher.java @@ -19,18 +19,22 @@ package
> org.apache.maven.surefire.its.fixture; * under the License.
>   */
> 
> +import org.apache.commons.lang.text.StrSubstitutor;
> +import org.apache.maven.it.VerificationException;
> +import org.apache.maven.it.Verifier;
> +import org.apache.maven.it.util.ResourceExtractor;
> +import org.apache.maven.shared.utils.io.FileUtils;
> +
>  import java.io.File;
>  import java.io.IOException;
>  import java.net.URL;
>  import java.util.ArrayList;
>  import java.util.HashMap;
>  import java.util.List;
> +import java.util.ListIterator;
>  import java.util.Map;
> -import org.apache.commons.lang.text.StrSubstitutor;
> -import org.apache.maven.it.VerificationException;
> -import org.apache.maven.it.Verifier;
> -import org.apache.maven.it.util.ResourceExtractor;
> -import org.apache.maven.shared.utils.io.FileUtils;
> +
> +import static java.util.Collections.unmodifiableList;
> 
>  /**
>   * Encapsulate all needed features to start a maven run
> @@ -203,13 +207,13 @@ public class MavenLauncher
> 
>  public MavenLauncher skipClean()
>  {
> -goals.add( "-Dclean.skip=true" );
> +writeGoal( "-Dclean.skip=true" );
>  return this;
>  }
> 
>  public MavenLauncher addGoal( String goal )
>  {
> -goals.add( goal );
> +writeGoal( goal );
>  return this;
>  }
> 
> @@ -223,6 +227,33 @@ public class MavenLauncher
>  return conditionalExec( "test" );
>  }
> 
> +List getGoals()
> +{
> +return unmodifiableList( goals );
> +}
> +
> +private void writeGoal( String newGoal )
> +{
> +if ( newGoal != null && newGoal.startsWith( "-D" ) )
> +{
> +final String sysPropKey =
> +newGoal.contains( "=" ) ? newGoal.substring( 0,
> newGoal.indexOf( '=' ) ) : newGoal; +
> +final String sysPropStarter = sysPropKey + "=";
> +
> +for ( ListIterator it = goals.listIterator();
> it.hasNext(); ) +{
> +String goal = it.next();
> +if ( goal.equals( sysPropKey ) || goal.startsWith(
> sysPropStarter ) ) +{
> +it.set( newGoal );
> +return;
> +}
> +}
> +}
> +goals.add( newGoal );
> +}
> +
>  private OutputValidator conditionalExec(String goal)
>  {
>  OutputValidator verify;
> 
> http://git-wip-us.apache.org/repos/asf/maven-surefire/blob/ef5b0f46/surefire
> -integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/Maven
> LauncherTest.java
> -- diff
>

Re: I think we are ready for 3.5.0-alpha-1

On Sat 18 Feb 2017 at 11:19, Hervé BOUTEMY  wrote:

> the discussion is not about merging some code from a branch to master: it's
> about doing an alpha release from master
>

The current issue with surefire where forked tests will fail on at least
FreeBSD - as long as it is a clear regression from 3.3.9 - is a blocker on
an alpha.

If it is not a regression on 3.3.9 then it isn't a blocker.

I have not seen any other issues that merit blocking an alpha (but not
looked hard yet, so there may be others)

We need to start shaking down, so imho unless S1/S2 or a trivial S3 fix, it
has missed the boat for 3.5.0 if not landed already.


> then do you have concerns about doing an alpha release from master?
>
> or did I miss something? (which branch?)
>
> Regards,
>
> Hervé
>
> Le samedi 18 février 2017, 11:45:17 CET Robert Scholte a écrit :
> > For me it is a -1 to merge. It is not a regression compared to 3.3.9, so
> > that issue is not a blocker for me and can be part of a next release.
> >
> > Robert
> >
> > On Sat, 18 Feb 2017 09:29:51 +0100, Tibor Digana
> >
> >  wrote:
> > > +1: changed previous Vote, I want to see colors in console, but Karl
> > > should
> > > explain to Robert's remark that the change was a workaround. If it is
> > > Multithreading Memory Model problem, we can find better fix together.
> But
> > > now the contains() method is part of logic and dev will try to see it
> > > reasonable logic not knowing it was a workaround.
> > >
> > > On Fri, Feb 17, 2017 at 7:18 PM, Stephen Connolly <
> > >
> > > stephen.alan.conno...@gmail.com> wrote:
> > >> Would it help yet to cut an alpha and start tracking bugs?
> > >>
> > >> I am starting to be concerned that the collective of volunteers are
> on a
> > >> death march with no end in site... so I am seeking ways to identify an
> > >> end
> > >> where we can cut 3.5.0 and start on 3.5.1
> > >>
> > >> I don't want to be here in 2-3 weeks and still not even a
> 3.5.0-alpha-1
> > >> that users could start testing
> > >>
> > >> On Fri 17 Feb 2017 at 18:10, Michael Osipov 
> wrote:
> > >> > Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > >> > > Is there someone who tried to deploy a "large" artifact ?
> > >> > >
> > >> > > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> > >> > >
> > >> > > The project : https://github.com/jenkinsci/maven-plugin
> > >> >
> > >> > > Downloading:
> > >> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > >>
> > >> maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > >>
> > >> > > Downloaded:
> > >> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > >>
> > >> maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > >>
> > >> > > (929 B at 1.5 kB/s)
> > >> >
> > >> > > Uploading:
> > >> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > >>
> > >> maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
> > >>
> > >> > > [INFO] I/O exception (java.net.SocketException) caught when
> > >>
> > >> processing
> > >>
> > >> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe
> (Write
> > >> >
> > >> > failed)
> > >> >
> > >> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > >> > > [INFO] I/O exception (java.net.SocketException) caught when
> > >>
> > >> processing
> > >>
> > >> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe
> (Write
> > >> >
> > >> > failed)
> > >> >
> > >> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > >> > > [INFO] I/O exception (java.net.SocketException) caught when
> > >>
> > >> processing
> > >>
> > >> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe
> (Write
> > >> >
> > >> > failed)
> > >> >
> > >> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > >> >
> > >> > In Wagon 2.12 Apache HttpComponents have been upgraded:
> > >> > > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > >> > > index 1995fb7..e29dd55 100644
> > >> > > --- a/wagon-providers/pom.xml
> > >> > > +++ b/wagon-providers/pom.xml
> > >> > > @@ -23,7 +23,7 @@ under the License.
> > >> > >
> > >> > >
> > >> > >
> > >> > >  org.apache.maven.wagon
> > >> > >  wagon
> > >> > >
> > >> > > -2.10
> > >> > > +2.12
> > >> > >
> > >> > >  ../pom.xml
> > >> > >
> > >> > >
> > >> > >
> > >> > > @@ -50,12 +50,12 @@ under the License.
> > >> > >
> > >> > >
> > >> > >
> > >> > >  org.apache.httpcomponents
> > >> > >  httpclient
> > >> > >
> > >> > > -4.3.5
> > >> > > +4.5.2
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >  org.apache.httpcomponents
> > >> > >  httpcore
> > >> > >
> > >> > > -4.3.2
> > >> > > +4.4.4
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >  org.apache.sshd
> > >> >
> > >> > Additionally, the log dependencies where incorrectly

Re: I think we are ready for 3.5.0-alpha-1

the discussion is not about merging some code from a branch to master: it's 
about doing an alpha release from master

then do you have concerns about doing an alpha release from master?

or did I miss something? (which branch?)

Regards,

Hervé

Le samedi 18 février 2017, 11:45:17 CET Robert Scholte a écrit :
> For me it is a -1 to merge. It is not a regression compared to 3.3.9, so
> that issue is not a blocker for me and can be part of a next release.
> 
> Robert
> 
> On Sat, 18 Feb 2017 09:29:51 +0100, Tibor Digana
> 
>  wrote:
> > +1: changed previous Vote, I want to see colors in console, but Karl
> > should
> > explain to Robert's remark that the change was a workaround. If it is
> > Multithreading Memory Model problem, we can find better fix together. But
> > now the contains() method is part of logic and dev will try to see it
> > reasonable logic not knowing it was a workaround.
> > 
> > On Fri, Feb 17, 2017 at 7:18 PM, Stephen Connolly <
> > 
> > stephen.alan.conno...@gmail.com> wrote:
> >> Would it help yet to cut an alpha and start tracking bugs?
> >> 
> >> I am starting to be concerned that the collective of volunteers are on a
> >> death march with no end in site... so I am seeking ways to identify an
> >> end
> >> where we can cut 3.5.0 and start on 3.5.1
> >> 
> >> I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> >> that users could start testing
> >> 
> >> On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:
> >> > Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> >> > > Is there someone who tried to deploy a "large" artifact ?
> >> > > 
> >> > > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> >> > > 
> >> > > The project : https://github.com/jenkinsci/maven-plugin
> >> > 
> >> > > Downloading:
> >> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> >> 
> >> maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> >> 
> >> > > Downloaded:
> >> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> >> 
> >> maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> >> 
> >> > > (929 B at 1.5 kB/s)
> >> > 
> >> > > Uploading:
> >> > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> >> 
> >> maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
> >> 
> >> > > [INFO] I/O exception (java.net.SocketException) caught when
> >> 
> >> processing
> >> 
> >> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> >> > 
> >> > failed)
> >> > 
> >> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> >> > > [INFO] I/O exception (java.net.SocketException) caught when
> >> 
> >> processing
> >> 
> >> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> >> > 
> >> > failed)
> >> > 
> >> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> >> > > [INFO] I/O exception (java.net.SocketException) caught when
> >> 
> >> processing
> >> 
> >> > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> >> > 
> >> > failed)
> >> > 
> >> > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> >> > 
> >> > In Wagon 2.12 Apache HttpComponents have been upgraded:
> >> > > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> >> > > index 1995fb7..e29dd55 100644
> >> > > --- a/wagon-providers/pom.xml
> >> > > +++ b/wagon-providers/pom.xml
> >> > > @@ -23,7 +23,7 @@ under the License.
> >> > > 
> >> > >
> >> > >
> >> > >  org.apache.maven.wagon
> >> > >  wagon
> >> > > 
> >> > > -2.10
> >> > > +2.12
> >> > > 
> >> > >  ../pom.xml
> >> > >
> >> > >
> >> > > 
> >> > > @@ -50,12 +50,12 @@ under the License.
> >> > > 
> >> > >
> >> > >
> >> > >  org.apache.httpcomponents
> >> > >  httpclient
> >> > > 
> >> > > -4.3.5
> >> > > +4.5.2
> >> > > 
> >> > >
> >> > >
> >> > >
> >> > >  org.apache.httpcomponents
> >> > >  httpcore
> >> > > 
> >> > > -4.3.2
> >> > > +4.4.4
> >> > > 
> >> > >
> >> > >
> >> > >
> >> > >  org.apache.sshd
> >> > 
> >> > Additionally, the log dependencies where incorrectly configured which
> >> > has been corrected in another ticket.
> >> > 
> >> > Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> >> > file, we can easily add a HugeFileUploadTest.
> >> > 
> >> > Looking at the log messages issued by the HttpComponents, you have a
> >> > network issue. Somewhere between you and the Artifactory instance the
> >> > connection has been terminated (broken pipe).
> >> > 
> >> > Can you repeat this issue realiably?
> >> > 
> >> > Michael
> >> > 
> >> > 
> >> > 
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> > 
> >> > --
> >> 
> >>

Re: I think we are ready for 3.5.0-alpha-1

2017-02-18 Thread Karl Heinz Marbaise

Hi Robert,

On 17/02/17 17:24, Robert Scholte wrote:

Hi Karl Heinz,

looking at the commit[1] I see that the projectBuildList.contains will
prevent the NPE, but it looks weird to me that the projectBuildList does
not contain a mavenProject which was marked as finished so can be built.
Why is it null?

This is most important question..here...

I have started to dive more into the details here...

If there's no clear reason yet, there should be at least an
else-statement logging this.
Looks to me more like a NPE prevention instead of fixing the root cause.

Yes ..

-1 for me.

So -1 from me too...

This can wait unit I know more about the details and more about the why...

Thanks for brining up important question..

Kind regards
Karl Heinz

thanks,
Robert

[1]
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commitdiff;h=238f789ad07a18c0dff7f884c9a5d3b47258fc47

On Fri, 17 Feb 2017 16:56:23 +0100, Karl Heinz Marbaise
wrote:

Hi,

I have identified a bug[1] in Maven Core based on an issue related to
versions-maven-plugin:

I have made already a fix for it and all tests are running[2].

Any objection to merge that issue into master ?

Kind regards
Karl Heinz Marbaise

[1]: https://issues.apache.org/jira/browse/MNG-6170
[2]:
https://builds.apache.org/view/M-R/view/Maven/job/maven-3.x-jenkinsfile/job/MNG-6170/

On 08/02/17 21:01, Stephen Connolly wrote:

I think all the important stuff is merged. I'll take a final review
through
and then cut alpha-1

We can still add stuff if necessary for an alpha-2 but I'd much
prefer to
focus that on shaking out bugs.

Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
which point it should only be serious bug fixes)

Then we give the beta some soak and cut the release

I toyed with spinning RCs but I'm thinking alpha and beta are better
terms

Thoughts?

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

Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen http://www.soebes.de

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

Re: Recent issues found in Surefire master/Maven Clean Plugin 3.0.0 with Maven master

2017-02-18 Thread Michael Osipov


For those who would like to reproduce the issues:

1. Build Maven distribution from 3.3.9, master, MNG-6169 and MNG-6169 
with locally modified 
maven-core/src/main/resources/META-INF/plexus/components.xml 
maven-clean-plugin 2.6.1 => 3.0.0.

You should have four distros now.
2. Clone Surefire
3. Run all four versions of Maven against Surefire master:
> ~/apache-maven-$version/bin/mvn -B -V clean install 
-Dinvoker.mergeSettings | tee ~/maven-surefire.log

Leave mergeSettings out if you have direct Internet connection
4. Save maven-surefire.log and surefire-integration-tests/target for 
later analysis

5. Branch off Surefire master and apply branches:
origin/SUREFIRE_STDOUT_FLUSH
origin/SUREFIRE_SYSPROP_DUPLICATES
6. Repeat step 3
7. Checkout maven-shared-utils-0.9.x from Subversion, install and update 
maven-surefire/pom.xml with version 0.9.1-SNAPSHOT

8. Repeat 6
7. Compare results of 3, 5, 6, 8 as well as with my maven-surefire.log files

note: my logs are based on an already patched version (from mentioned 
branches) of Surefire master.


Michael

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

Re: I think we are ready for 3.5.0-alpha-1

For me it is a -1 to merge. It is not a regression compared to 3.3.9, so  
that issue is not a blocker for me and can be part of a next release.


Robert

On Sat, 18 Feb 2017 09:29:51 +0100, Tibor Digana  
 wrote:


+1: changed previous Vote, I want to see colors in console, but Karl  
should

explain to Robert's remark that the change was a workaround. If it is
Multithreading Memory Model problem, we can find better fix together. But
now the contains() method is part of logic and dev will try to see it
reasonable logic not knowing it was a workaround.

On Fri, Feb 17, 2017 at 7:18 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:


Would it help yet to cut an alpha and start tracking bugs?

I am starting to be concerned that the collective of volunteers are on a
death march with no end in site... so I am seeking ways to identify an  
end

where we can cut 3.5.0 and start on 3.5.1

I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
that users could start testing

On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:

> Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > Is there someone who tried to deploy a "large" artifact ?
> >
> > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> >
> > The project : https://github.com/jenkinsci/maven-plugin
> > Downloading:
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > Downloaded:
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > (929 B at 1.5 kB/s)
> > Uploading:
> >
> https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
> > [INFO] I/O exception (java.net.SocketException) caught when  
processing

> > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> failed)
> > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > [INFO] I/O exception (java.net.SocketException) caught when  
processing

> > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> failed)
> > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > [INFO] I/O exception (java.net.SocketException) caught when  
processing

> > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> failed)
> > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
>
> In Wagon 2.12 Apache HttpComponents have been upgraded:
> > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > index 1995fb7..e29dd55 100644
> > --- a/wagon-providers/pom.xml
> > +++ b/wagon-providers/pom.xml
> > @@ -23,7 +23,7 @@ under the License.
> >
> >  org.apache.maven.wagon
> >  wagon
> > -2.10
> > +2.12
> >  ../pom.xml
> >
> >
> > @@ -50,12 +50,12 @@ under the License.
> >
> >  org.apache.httpcomponents
> >  httpclient
> > -4.3.5
> > +4.5.2
> >
> >
> >  org.apache.httpcomponents
> >  httpcore
> > -4.3.2
> > +4.4.4
> >
> >
> >  org.apache.sshd
>
> Additionally, the log dependencies where incorrectly configured which
> has been corrected in another ticket.
>
> Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> file, we can easily add a HugeFileUploadTest.
>
> Looking at the log messages issued by the HttpComponents, you have a
> network issue. Somewhere between you and the Artifactory instance the
> connection has been terminated (broken pipe).
>
> Can you repeat this issue realiably?
>
> Michael
>
>
>
> -
> 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

Re: I think we are ready for 3.5.0-alpha-1

After chatting on IRC I see this surefire issue on at least FreeBSD as a
blocker for an alpha.

We need help testing on Solaris 10/11 if anyone has access to such a system

On Sat 18 Feb 2017 at 09:56, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> If I am cutting an alpha and it contains known issues, we should list them
> as such on release notes.
>
> I'll see what that would look like some time this weekend and categorise as
>
> S1: Maven blows up always - no workaround
> S2: Maven blows up under certain circumstances - no workaround
> S3: A workaround can prevent an S1/S2 or general regressions in build
> behaviour
> S4: non functional bugs (i.e. Logging output not how we want it, etc)
>
> If we have any S1/S2 I am not cutting an alpha until they are
> fixed/mediated to S3
>
> On Sat 18 Feb 2017 at 08:30, Tibor Digana 
> wrote:
>
> +1: changed previous Vote, I want to see colors in console, but Karl should
> explain to Robert's remark that the change was a workaround. If it is
> Multithreading Memory Model problem, we can find better fix together. But
> now the contains() method is part of logic and dev will try to see it
> reasonable logic not knowing it was a workaround.
>
> On Fri, Feb 17, 2017 at 7:18 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Would it help yet to cut an alpha and start tracking bugs?
> >
> > I am starting to be concerned that the collective of volunteers are on a
> > death march with no end in site... so I am seeking ways to identify an
> end
> > where we can cut 3.5.0 and start on 3.5.1
> >
> > I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> > that users could start testing
> >
> > On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:
> >
> > > Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > > > Is there someone who tried to deploy a "large" artifact ?
> > > >
> > > > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> > > >
> > > > The project : https://github.com/jenkinsci/maven-plugin
> > > > Downloading:
> > > >
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > > > Downloaded:
> > > >
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > > > (929 B at 1.5 kB/s)
> > > > Uploading:
> > > >
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
> > > > [INFO] I/O exception (java.net.SocketException) caught when
> processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > failed)
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > [INFO] I/O exception (java.net.SocketException) caught when
> processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > failed)
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > [INFO] I/O exception (java.net.SocketException) caught when
> processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > failed)
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > >
> > > In Wagon 2.12 Apache HttpComponents have been upgraded:
> > > > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > > > index 1995fb7..e29dd55 100644
> > > > --- a/wagon-providers/pom.xml
> > > > +++ b/wagon-providers/pom.xml
> > > > @@ -23,7 +23,7 @@ under the License.
> > > >
> > > >  org.apache.maven.wagon
> > > >  wagon
> > > > -2.10
> > > > +2.12
> > > >  ../pom.xml
> > > >
> > > >
> > > > @@ -50,12 +50,12 @@ under the License.
> > > >
> > > >  org.apache.httpcomponents
> > > >  httpclient
> > > > -4.3.5
> > > > +4.5.2
> > > >
> > > >
> > > >  org.apache.httpcomponents
> > > >  httpcore
> > > > -4.3.2
> > > > +4.4.4
> > > >
> > > >
> > > >  org.apache.sshd
> > >
> > > Additionally, the log dependencies where incorrectly configured which
> > > has been corrected in another ticket.
> > >
> > > Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> > > file, we can easily add a HugeFileUploadTest.
> > >
> > > Looking at the log messages issued by the HttpComponents, you have a
> > > network issue. Somewhere between you and the Artifactory instance the
> > > connection has been terminated (broken pipe).
> > >
> > > Can you repeat this issue realiably?
> > >
> > > Michael
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
> >
>
>
>
> --
> Cheers
> Tibor
>
> --
Sent from my phone

Re: I think we are ready for 3.5.0-alpha-1

If I am cutting an alpha and it contains known issues, we should list them
as such on release notes.

I'll see what that would look like some time this weekend and categorise as

S1: Maven blows up always - no workaround
S2: Maven blows up under certain circumstances - no workaround
S3: A workaround can prevent an S1/S2 or general regressions in build
behaviour
S4: non functional bugs (i.e. Logging output not how we want it, etc)

If we have any S1/S2 I am not cutting an alpha until they are
fixed/mediated to S3

On Sat 18 Feb 2017 at 08:30, Tibor Digana 
wrote:

> +1: changed previous Vote, I want to see colors in console, but Karl should
> explain to Robert's remark that the change was a workaround. If it is
> Multithreading Memory Model problem, we can find better fix together. But
> now the contains() method is part of logic and dev will try to see it
> reasonable logic not knowing it was a workaround.
>
> On Fri, Feb 17, 2017 at 7:18 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Would it help yet to cut an alpha and start tracking bugs?
> >
> > I am starting to be concerned that the collective of volunteers are on a
> > death march with no end in site... so I am seeking ways to identify an
> end
> > where we can cut 3.5.0 and start on 3.5.1
> >
> > I don't want to be here in 2-3 weeks and still not even a 3.5.0-alpha-1
> > that users could start testing
> >
> > On Fri 17 Feb 2017 at 18:10, Michael Osipov  wrote:
> >
> > > Am 2017-02-17 um 18:03 schrieb Arnaud Héritier:
> > > > Is there someone who tried to deploy a "large" artifact ?
> > > >
> > > > I have a bug in 3.5 and not in 3.3.9 but for now no time to dig
> > > >
> > > > The project : https://github.com/jenkinsci/maven-plugin
> > > > Downloading:
> > > >
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > > > Downloaded:
> > > >
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > maven-plugin/2.16-SNAPSHOT/maven-metadata.xml
> > > > (929 B at 1.5 kB/s)
> > > > Uploading:
> > > >
> > > https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/
> > maven-plugin/2.16-SNAPSHOT/maven-plugin-2.16-20170217.170023-3.hpi
> > > > [INFO] I/O exception (java.net.SocketException) caught when
> processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > failed)
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > [INFO] I/O exception (java.net.SocketException) caught when
> processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > failed)
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > > > [INFO] I/O exception (java.net.SocketException) caught when
> processing
> > > > request to {s}->https://repo.jenkins-ci.org:443: Broken pipe (Write
> > > failed)
> > > > [INFO] Retrying request to {s}->https://repo.jenkins-ci.org:443
> > >
> > > In Wagon 2.12 Apache HttpComponents have been upgraded:
> > > > diff --git a/wagon-providers/pom.xml b/wagon-providers/pom.xml
> > > > index 1995fb7..e29dd55 100644
> > > > --- a/wagon-providers/pom.xml
> > > > +++ b/wagon-providers/pom.xml
> > > > @@ -23,7 +23,7 @@ under the License.
> > > >
> > > >  org.apache.maven.wagon
> > > >  wagon
> > > > -2.10
> > > > +2.12
> > > >  ../pom.xml
> > > >
> > > >
> > > > @@ -50,12 +50,12 @@ under the License.
> > > >
> > > >  org.apache.httpcomponents
> > > >  httpclient
> > > > -4.3.5
> > > > +4.5.2
> > > >
> > > >
> > > >  org.apache.httpcomponents
> > > >  httpcore
> > > > -4.3.2
> > > > +4.4.4
> > > >
> > > >
> > > >  org.apache.sshd
> > >
> > > Additionally, the log dependencies where incorrectly configured which
> > > has been corrected in another ticket.
> > >
> > > Finally, we have a HugeFileDownloadTest which downloads a 4 GiB large
> > > file, we can easily add a HugeFileUploadTest.
> > >
> > > Looking at the log messages issued by the HttpComponents, you have a
> > > network issue. Somewhere between you and the Artifactory instance the
> > > connection has been terminated (broken pipe).
> > >
> > > Can you repeat this issue realiably?
> > >
> > > Michael
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
> >
>
>
>
> --
> Cheers
> Tibor
>
-- 
Sent from my phone

Re: I think we are ready for 3.5.0-alpha-1