date:20161228

>> Right now I see Wagon as a reference project for Maven 3.4.0:

I disagree. It relies on overriding management althought that correctly
is not supported when consumed.


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 03:19 schrieb Christian Schulte:
> Am 12/29/16 um 02:41 schrieb Christian Schulte:
>> Am 12/29/16 um 02:36 schrieb Christian Schulte:
>>> Am 12/29/16 um 00:41 schrieb Michael Osipov:
 If this is how it should (I am neither pro nor cons) work, we should 
 deprecate this element or at least put a big WARNING on it.
>>>
>>> We should spit out a big fat warning whenever someone overrides hers/his
>>> own management. It shouldn't even be possible to do so. That's not a
>>> feature :-)
>>
>> Ask a manager about that. Management is dominant. It should not be
>> possible to override that anywhere. The resolver should really override
>> direct dependencies with the management as well and not just transitive
>> ones. It currently does not only to not break this "feature".
> 
> Maybe more technically: Suppose the maven-plugins parent would manage
> versions of various components. Maven core, plexus archiver,
> plexus-utils, etc. This must be applied to all plugins using that parent
> no matter what a plugin declares itself. The author of that parent and
> the author of a plugin's POM are different persons. Maybe the parent can
> only be released by a PMC member and plugins can be released by
> committers etc. Allowing to override the management really is a bad idea.

So for model version 5.0.0 I would like to request to implement "final"
and maybe "override" semantics (for parents, if they still exist and for
mixins). There at least needs to be a way to express "final" declarations.


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:41 schrieb Christian Schulte:
> Am 12/29/16 um 02:36 schrieb Christian Schulte:
>> Am 12/29/16 um 00:41 schrieb Michael Osipov:
>>> If this is how it should (I am neither pro nor cons) work, we should 
>>> deprecate this element or at least put a big WARNING on it.
>>
>> We should spit out a big fat warning whenever someone overrides hers/his
>> own management. It shouldn't even be possible to do so. That's not a
>> feature :-)
> 
> Ask a manager about that. Management is dominant. It should not be
> possible to override that anywhere. The resolver should really override
> direct dependencies with the management as well and not just transitive
> ones. It currently does not only to not break this "feature".

Maybe more technically: Suppose the maven-plugins parent would manage
versions of various components. Maven core, plexus archiver,
plexus-utils, etc. This must be applied to all plugins using that parent
no matter what a plugin declares itself. The author of that parent and
the author of a plugin's POM are different persons. Maybe the parent can
only be released by a PMC member and plugins can be released by
committers etc. Allowing to override the management really is a bad idea.


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:36 schrieb Christian Schulte:
> Am 12/29/16 um 00:41 schrieb Michael Osipov:
>> If this is how it should (I am neither pro nor cons) work, we should 
>> deprecate this element or at least put a big WARNING on it.
> 
> We should spit out a big fat warning whenever someone overrides hers/his
> own management. It shouldn't even be possible to do so. That's not a
> feature :-)

Ask a manager about that. Management is dominant. It should not be
possible to override that anywhere. The resolver should really override
direct dependencies with the management as well and not just transitive
ones. It currently does not only to not break this "feature".


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 00:41 schrieb Michael Osipov:
> If this is how it should (I am neither pro nor cons) work, we should 
> deprecate this element or at least put a big WARNING on it.

We should spit out a big fat warning whenever someone overrides hers/his
own management. It shouldn't even be possible to do so. That's not a
feature :-)


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 02:12 schrieb Christian Schulte:
> Am 12/29/16 um 00:41 schrieb Michael Osipov:
>> Am 2016-12-28 um 22:51 schrieb Christian Schulte:
>>> I just pushed a fix for this. I could also have made that transitive
>>> dependency a direct one, where it is used, and could have left the scope
>>> management in.
>>>
>>> "Dependency management overrides are not transitive."
>>
>> Just checked this commit. It ultimately means that  is useless in 
>> dependency management unless you know all transitive dependencies in 
>> order not to break them.
> 
> Maven and the resolver have a different way of applying management. In
> Maven, the management is used as a source of default values to be used
> when those values are not provided otherwise (POM authoring - direct -
> you can declare everything yourself). The resolver uses it as a global
> override (POM consumption - transitive - you cannot do anything about
> those consumed POMs but need to able to do so -> management). It both
> makes sense somehow. What is inconsistent is to override management in a
> module and then consume that module transitively in another module as if
> it were something outside the reactor. All of the issues presented on
> dev@ so far were due to this (overridden management).
> 
>> If this is how it should (I am neither pro nor cons) work, we should 
>> deprecate this element or at least put a big WARNING on it.
> 
> We need to distinguish between the management applied when authoring a
> POM and the management applied when consuming a POM. There is two
> stories about it. In a multi-module project you are the author so you
> just use the dependency management to get rid of redundant dependency
> declarations (versions, scopes, etc. all in one place and left out
> everywhere).  When consuming a project, you want to control the
> dependencies the same way so your management is used to apply your
> declarations onto the consumed projects (global override).
> 
> Your POMs - you are the author in full control of everything:
> Do not override anything you have put into the management anywhere
> because that is what the resolver does as soon as a module is consumed
> transitively - either in the same reactor, or somewhere else.

Adding to this: The resolver does not know anything about the reactor or
modules. It resolves dependencies no matter what. Maybe that way: There
are no transitive modules and no special handling in resolving a
transitive module or a transitive dependency. That's where the
difference between direct and transitive is coming from.


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/29/16 um 00:41 schrieb Michael Osipov:
> Am 2016-12-28 um 22:51 schrieb Christian Schulte:
>> I just pushed a fix for this. I could also have made that transitive
>> dependency a direct one, where it is used, and could have left the scope
>> management in.
>>
>> "Dependency management overrides are not transitive."
> 
> Just checked this commit. It ultimately means that  is useless in 
> dependency management unless you know all transitive dependencies in 
> order not to break them.

Maven and the resolver have a different way of applying management. In
Maven, the management is used as a source of default values to be used
when those values are not provided otherwise (POM authoring - direct -
you can declare everything yourself). The resolver uses it as a global
override (POM consumption - transitive - you cannot do anything about
those consumed POMs but need to able to do so -> management). It both
makes sense somehow. What is inconsistent is to override management in a
module and then consume that module transitively in another module as if
it were something outside the reactor. All of the issues presented on
dev@ so far were due to this (overridden management).

> If this is how it should (I am neither pro nor cons) work, we should 
> deprecate this element or at least put a big WARNING on it.

We need to distinguish between the management applied when authoring a
POM and the management applied when consuming a POM. There is two
stories about it. In a multi-module project you are the author so you
just use the dependency management to get rid of redundant dependency
declarations (versions, scopes, etc. all in one place and left out
everywhere).  When consuming a project, you want to control the
dependencies the same way so your management is used to apply your
declarations onto the consumed projects (global override).

Your POMs - you are the author in full control of everything:
Do not override anything you have put into the management anywhere
because that is what the resolver does as soon as a module is consumed
transitively - either in the same reactor, or somewhere else.


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

Re: [VOTE] Releasing Wagon 2.11


Am 2016-12-28 um 21:34 schrieb Guillaume Boué:

I have the same results as Hervé, both on Windows and Ubuntu. This is
what I have with Maven 3.3.9:

- Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in
HugeFileDownloadTest (perhaps the timeout should be increased?)


How often did you run the tests to get this result? I tried at least 20 
times or more.

Can you enable the logging I asked Dan for? You might see something else.

By timeout do you mean the timeout Surefire waits for the forked VM?

Can you try the attached patch? I have noticed that in this 
HugeFileDownloadTest the server is never shutdown as well as in other cases.


Michael

diff --git 
a/wagon-provider-test/src/main/java/org/apache/maven/wagon/http/HttpWagonTestCase.java
 
b/wagon-provider-test/src/main/java/org/apache/maven/wagon/http/HttpWagonTestCase.java
index 172d5be..c19eaa3 100644
--- 
a/wagon-provider-test/src/main/java/org/apache/maven/wagon/http/HttpWagonTestCase.java
+++ 
b/wagon-provider-test/src/main/java/org/apache/maven/wagon/http/HttpWagonTestCase.java
@@ -715,6 +715,7 @@ public void testRedirectGetToStream()
 {
 wagon.disconnect();
 
+redirectServer.stop();
 realServer.stop();
 
 tmpResult.delete();
@@ -776,6 +777,7 @@ public void testRedirectGet()
 {
 wagon.disconnect();
 
+redirectServer.stop();
 realServer.stop();
 
 tmpResult.delete();
@@ -851,9 +853,9 @@ public void testRedirectPutFromStreamWithFullUrl()
 }
 finally
 {
+wagon.disconnect();
 fileInputStream.close();
 tempFile.delete();
-
 }
 
 }
@@ -923,9 +925,9 @@ public void testRedirectPutFromStreamRelativeUrl()
 }
 finally
 {
+wagon.disconnect();
 fileInputStream.close();
 tempFile.delete();
-
 }
 
 }
@@ -1029,6 +1031,7 @@ public void testRedirectPutFileWithFullUrl()
 }
 finally
 {
+wagon.disconnect();
 tempFile.delete();
 }
 
@@ -1092,6 +1095,7 @@ public void testRedirectPutFileRelativeUrl()
 }
 finally
 {
+wagon.disconnect();
 tempFile.delete();
 }
 
diff --git 
a/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java
 
b/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java
index 6692988..41da7d4 100644
--- 
a/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java
+++ 
b/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java
@@ -59,7 +59,7 @@ protected int getTestRepositoryPort() {
 /**
  * This test is introduced to allow for null file wagons.
  * Which is used heavily in the maven component ITs.
- * 
+ *
  * @throws ConnectionException
  * @throws AuthenticationException
  */
@@ -70,28 +70,29 @@ public void testNullFileWagon() throws ConnectionException, 
AuthenticationExcept
 resource.setContentLength( 10 );
 Repository repository = new Repository();
 wagon.connect( repository );
+wagon.disconnect();
 }
 
 protected long getExpectedLastModifiedOnGet( Repository repository, 
Resource resource )
 {
 return new File( repository.getBasedir(), resource.getName() 
).lastModified();
 }
-
+
 public void testResourceExists()
 throws Exception
 {
 String url = "file://" + getBasedir();
-
+
 Wagon wagon = new FileWagon();
 Repository repository = new Repository( "someID", url );
 wagon.connect( repository );
-
+
 assertTrue( wagon.resourceExists( "target" ) );
 assertTrue( wagon.resourceExists( "target/" ) );
 assertTrue( wagon.resourceExists( "pom.xml" ) );
-
+
 assertFalse( wagon.resourceExists( "pom.xml/" ) );
-
+
 wagon.disconnect();
 }
 }
diff --git 
a/wagon-providers/wagon-http/src/test/java/org/apache/maven/wagon/providers/http/AbstractHttpClientWagonTest.java
 
b/wagon-providers/wagon-http/src/test/java/org/apache/maven/wagon/providers/http/AbstractHttpClientWagonTest.java
index c1814f4..15b1f6b 100644
--- 
a/wagon-providers/wagon-http/src/test/java/org/apache/maven/wagon/providers/http/AbstractHttpClientWagonTest.java
+++ 
b/wagon-providers/wagon-http/src/test/java/org/apache/maven/wagon/providers/http/AbstractHttpClientWagonTest.java
@@ -47,5 +47,7 @@ public void test()
 inputData.setResource( resource );
 
 wagon.fillInputData( inputData );
+
+wagon.disconnect();
 }
 }
diff --git

Re: [VOTE] Releasing Wagon 2.11


Am 2016-12-28 um 22:51 schrieb Christian Schulte:

I just pushed a fix for this. I could also have made that transitive
dependency a direct one, where it is used, and could have left the scope
management in.

"Dependency management overrides are not transitive."


Just checked this commit. It ultimately means that  is useless in 
dependency management unless you know all transitive dependencies in 
order not to break them.


If this is how it should (I am neither pro nor cons) work, we should 
deprecate this element or at least put a big WARNING on it.


Michael


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

Re: [VOTE] Releasing Wagon 2.11


Am 2016-12-28 um 22:50 schrieb Robert Scholte:

Which makes me wonder if this really is a fix. Wagon can be built with a
wide range of Maven version covering a lot of years AND the
maven-dependency-plugin shows what you would expect: junit is available
with test-scope.

"That's always been that way."
Well, apparently not. Maybe it was documented that way, but I expect
that users did their dependency management which felt natural and which
worked.

I'm afraid that this is exactly where Jason was warning you for.
Right now I see Wagon as a reference project for Maven 3.4.0: it should
still work without the pom adjustments, because its original setup made
sense.


Just a side note: I clean up a lot of dependency issues with a separate 
ticket (WAGON-471) because deps were transitive but never declared in 
the POM. Right now, with Maven 3.4.0-SNAPSHOT, it does not work because 
resolution is different. I have obstained to test with Maven 
3.4.0-SNAPSHOT because I wanted to focus on the Wagon issues.



Michael

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

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué:
> 
> How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?
> 

I'd say this is the root cause of nearly all issues we are having a hard
time fixing and shipping. It does not make sense to compare some recent
behaviour to some former behaviour when that former behaviour is a
result of patches trying to make things behave in a way users expect it.
Using Maven 2.x or 3.x as the specification of how things /should/
behave when even the documentation says things really are meant to be
different than what we ship is rediculous, IMHO. What we now have on
master is consistent with itself and matches the documentation. That's
how Maven 2.0.0 should have behaved from day one but did not. The
documentation in this area has not been changed for more than nearly a
decade. Maven never behaved that way. I am not kean on endless
discussions about things. I do not have enough experience with GIT. Just
create a branch of current master and then reset master to 3.3.9 so that
I can squash and merge issues for the next release one by one into
master and get master into a state it would pass a release vote. That's
what I was refering to with "release branch". Passes a release build,
passes all core and plugin ITs and passes a release vote. Master clearly
does not pass a release vote. Hopefully what will pass a release vote is
not just coloured output.


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué:
> This is the tree with Maven 3.3.9:
> 
> [DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
> [DEBUG]org.slf4j:slf4j-simple:jar:1.7.19:test
> [DEBUG]   org.slf4j:slf4j-api:jar:1.7.19:test
> [DEBUG]org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
> [DEBUG]org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT:test
> [DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.5.5:test
> [DEBUG]  org.codehaus.plexus:plexus-classworlds:jar:2.2.2:test
> [DEBUG]  org.apache.xbean:xbean-reflect:jar:3.4:test
> [DEBUG] log4j:log4j:jar:1.2.12:test
> [DEBUG] commons-logging:commons-logging-api:jar:1.1:test
> [DEBUG]  com.google.collections:google-collections:jar:1.0:test
> [DEBUG]   org.easymock:easymock:jar:3.2:test
> [DEBUG]  cglib:cglib-nodep:jar:2.2.2:test
> [DEBUG]  org.objenesis:objenesis:jar:1.3:test
> [DEBUG]   org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:test
> [DEBUG]  
> org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:test
> [DEBUG]   javax.servlet:javax.servlet-api:jar:3.0.1:test
> [DEBUG]   junit:junit:jar:4.11:test (scope managed from compile by 
> org.apache.maven.wagon:wagon:2.12-SNAPSHOT)
> [DEBUG]  org.hamcrest:hamcrest-core:jar:1.3:test

You have overridden the test scope from management in the POM to
compile. Why would you expect Maven to override that from the management
transitively?

I mean this:

(scope managed from compile by org.apache.maven.wagon:wagon:2.12-SNAPSHOT)

That compile is the override in the POM. In the POM you told Maven to
ignore the test scope from management and override that with compile.
Why are you expecting Maven to ignore your override?


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

Re: [VOTE] Releasing Wagon 2.11

To be even more clear: It's bullshit you can override the management in
the POM when those overrides disappear transitively. Do not override
management and be done with it.


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:50 schrieb Robert Scholte:
> Which makes me wonder if this really is a fix. Wagon can be built with a  
> wide range of Maven version covering a lot of years AND the  
> maven-dependency-plugin shows what you would expect: junit is available  
> with test-scope.
> 
> "That's always been that way."
> Well, apparently not. Maybe it was documented that way, but I expect that  
> users did their dependency management which felt natural and which worked.

The scope from management has been overridden in the POM and the
resolver is overriding that override with the management. That's what
makes no sense but there is no way to make the resolver not override
those overrides. It cannot detect them. And that really has always been
that way.

> Right now I see Wagon as a reference project for Maven 3.4.0: it should  
> still work without the pom adjustments, because its original setup made  
> sense.

I am not the person designing the test scope to be non-transitive. I
just made it behave that way consistently.


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

Re: [VOTE] Releasing Wagon 2.11

Le mercredi 28 décembre 2016, 22:50:52 CET Robert Scholte a écrit :
> Which makes me wonder if this really is a fix. Wagon can be built with a
> wide range of Maven version covering a lot of years AND the
> maven-dependency-plugin shows what you would expect: junit is available
> with test-scope.
> 
> "That's always been that way."
> Well, apparently not. Maybe it was documented that way, but I expect that
> users did their dependency management which felt natural and which worked.
> 
> I'm afraid that this is exactly where Jason was warning you for.
> Right now I see Wagon as a reference project for Maven 3.4.0: it should
> still work without the pom adjustments, because its original setup made
> sense.
+1

> 
> Robert
> 
> On Wed, 28 Dec 2016 22:31:52 +0100, Christian Schulte 
> 
> wrote:
> > Am 12/28/16 um 22:21 schrieb Guillaume Boué:
> >> How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?
> > 
> > Because it does not come with MRESOLVER-9 fixed.
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: [VOTE] Releasing Wagon 2.11

I just pushed a fix for this. I could also have made that transitive
dependency a direct one, where it is used, and could have left the scope
management in.

"Dependency management overrides are not transitive."


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

Re: [VOTE] Releasing Wagon 2.11

2016-12-28 Thread Robert Scholte

Which makes me wonder if this really is a fix. Wagon can be built with a  
wide range of Maven version covering a lot of years AND the  
maven-dependency-plugin shows what you would expect: junit is available  
with test-scope.


"That's always been that way."
Well, apparently not. Maybe it was documented that way, but I expect that  
users did their dependency management which felt natural and which worked.


I'm afraid that this is exactly where Jason was warning you for.
Right now I see Wagon as a reference project for Maven 3.4.0: it should  
still work without the pom adjustments, because its original setup made  
sense.


Robert

On Wed, 28 Dec 2016 22:31:52 +0100, Christian Schulte   
wrote:



Am 12/28/16 um 22:21 schrieb Guillaume Boué:


How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?


Because it does not come with MRESOLVER-9 fixed.


-
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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

Le mercredi 28 décembre 2016, 14:33:58 CET Robert Scholte a écrit :
> On Wed, 28 Dec 2016 11:47:40 +0100, Hervé BOUTEMY 
> 
> wrote:
> > Le mardi 27 décembre 2016, 14:48:56 CET Robert Scholte a écrit :
> >> >> The fact right now is that if I add/change a test-scoped dependency,
> >> 
> >> it
> >> 
> >> >> could happen that the project won't run due to a missing transitive
> >> >> dependency.
> >> >> We are very, very lucky this doesn't happen that often.
> >> > 
> >> > This is what would stop if we would just fix those bugs. We are
> >> 
> >> running
> >> 
> >> > into those bugs ourselves. Take a look at the PMD plugin POM again.
> >> 
> >> What
> >> 
> >> > would you have done, if the test dependencies I moved to compile scope
> >> > would be required for compilation of that project?
> >> 
> >> With the current behavior I wouldn't include these dependencies at all,
> >> since they're already available as compile-scoped transitive dependency.
> >> When due to an upgrade of a dependency commons-io is not used anymore,
> >> tests will fail to compile. And that's the moment to add this
> >> dependency.
> >> IMO changing dependencies should never cause compilation failures caused
> >> by transitive dependencies, but right now there's simply no better
> >> solution. We say that it is a best practice to always define the direct
> >> dependencies, but in this case we can't do that because we cannot give
> >> these dependencies the test-scope.
> > 
> > notice that this seems to have been reported years ago:
> > https://issues.apache.org/jira/browse/MNG-5739
> > 
> > and IMHO, if this case was fixed (which seems reasonable), MNG-6135
> > would not
> > break so many plugins (which do not have really broken config: having to
> > avoid
> > a test scope dependency just because it will override a transitive
> > compile
> > dependency is just the trial and error configuration people will have to
> > do)
> 
> You fully hit the nail. Before MNG-6135 the resolution was working as
> expected, even though it may seem as a very simplified dependency
> resolution: only look at direct compile+runtime -scoped dependencies and
> their transitive deps. In fact, I like this concept in general: pick all
> direct dependencies matching one or more scopes and all their transitive
> dependencies.
> To me there are 2 solutions: either implement MNG-5739 or revert MNG-6135.
> Any of both solutions will make plugins again run as expected.
+1

> 
> Robert
> 
> > Regards,
> > 
> > Hervé
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org



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

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 22:21 schrieb Guillaume Boué:
> 
> How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?

Because it does not come with MRESOLVER-9 fixed.


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

Re: [VOTE] Releasing Wagon 2.11

2016-12-28 Thread Guillaume Boué



Le 28/12/2016 à 21:49, Christian Schulte a écrit :

Am 12/28/16 um 21:34 schrieb Guillaume Boué:

I have the same results as Hervé, both on Windows and Ubuntu. This is
what I have with Maven 3.3.9:

- Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in
HugeFileDownloadTest (perhaps the timeout should be increased?)
- Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK
- Ubuntu 16.04 32bit, OpenJDK 1.7.0_95, Maven 3.3.9: All OK

With Maven 3.4.0-SNAPSHOT (65960ac18c8121648fe163612375a2ba5f4535c2), I
have compilation errors in the test class FileWagonTest (both on Windows
and Ubuntu)

[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[37,8]
 cannot access junit.framework.TestCase
class file for junit.framework.TestCase not found
[ERROR] 
/home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[48,52]
 cannot find symbol
symbol:   method getName()
location: class org.apache.maven.wagon.providers.file.FileWagonTest

The JUnit dependency isn't getting pulled. This is the scenario at hand:

- wagon-file has as parent wagon-providers which has a dependency on
wagon-provider-test with scope test.
- wagon-provider-test has a compile scoped dependency on junit
(compile is explicitly written).
- wagon-provider-test has as parent wagon, which has a test scoped
dependency management on junit.

What would be the problem?

Overriding the dependency management is only possible in the direct
dependencies (in the POM). When resolving a dependency, those overrides
are beeing ignored and the management gets applied. That's always been
that way. If your test classes need junit, you should declare junit in
the POM and not rely on it to be there transitively. The dependency
plugin's analyze goal would warn about this for the main artifact
(src/main) but not for the test artifact (src/test).



How come the tests compile fine with Maven 2.2.1, 3.0.5 and 3.3.9 then?

This is the tree with Maven 3.3.9:

[DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]org.slf4j:slf4j-simple:jar:1.7.19:test
[DEBUG]   org.slf4j:slf4j-api:jar:1.7.19:test
[DEBUG]org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT:test
[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.5.5:test
[DEBUG]  org.codehaus.plexus:plexus-classworlds:jar:2.2.2:test
[DEBUG]  org.apache.xbean:xbean-reflect:jar:3.4:test
[DEBUG] log4j:log4j:jar:1.2.12:test
[DEBUG] commons-logging:commons-logging-api:jar:1.1:test
[DEBUG]  com.google.collections:google-collections:jar:1.0:test
[DEBUG]   org.easymock:easymock:jar:3.2:test
[DEBUG]  cglib:cglib-nodep:jar:2.2.2:test
[DEBUG]  org.objenesis:objenesis:jar:1.3:test
[DEBUG]   org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:test
[DEBUG]  
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:test
[DEBUG]   javax.servlet:javax.servlet-api:jar:3.0.1:test
[DEBUG]   junit:junit:jar:4.11:test (scope managed from compile by 
org.apache.maven.wagon:wagon:2.12-SNAPSHOT)
[DEBUG]  org.hamcrest:hamcrest-core:jar:1.3:test





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




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


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

Re: [VOTE] Releasing Wagon 2.11

Am 12/28/16 um 21:34 schrieb Guillaume Boué:
> I have the same results as Hervé, both on Windows and Ubuntu. This is 
> what I have with Maven 3.3.9:
> 
> - Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in 
> HugeFileDownloadTest (perhaps the timeout should be increased?)
> - Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK
> - Ubuntu 16.04 32bit, OpenJDK 1.7.0_95, Maven 3.3.9: All OK
> 
> With Maven 3.4.0-SNAPSHOT (65960ac18c8121648fe163612375a2ba5f4535c2), I 
> have compilation errors in the test class FileWagonTest (both on Windows 
> and Ubuntu)
> 
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR] 
> /home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[37,8]
>  cannot access junit.framework.TestCase
>class file for junit.framework.TestCase not found
> [ERROR] 
> /home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[48,52]
>  cannot find symbol
>symbol:   method getName()
>location: class org.apache.maven.wagon.providers.file.FileWagonTest
> 
> The JUnit dependency isn't getting pulled. This is the scenario at hand:
> 
> - wagon-file has as parent wagon-providers which has a dependency on 
> wagon-provider-test with scope test.
> - wagon-provider-test has a compile scoped dependency on junit 
> (compile is explicitly written).
> - wagon-provider-test has as parent wagon, which has a test scoped 
> dependency management on junit.
> 
> What would be the problem?

Overriding the dependency management is only possible in the direct
dependencies (in the POM). When resolving a dependency, those overrides
are beeing ignored and the management gets applied. That's always been
that way. If your test classes need junit, you should declare junit in
the POM and not rely on it to be there transitively. The dependency
plugin's analyze goal would warn about this for the main artifact
(src/main) but not for the test artifact (src/test).



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

Re: [VOTE] Releasing Wagon 2.11

2016-12-28 Thread Guillaume Boué

I have the same results as Hervé, both on Windows and Ubuntu. This is 
what I have with Maven 3.3.9:


- Windows 10 64bit, OpenJDK 1.8.0_102, Test failure: Timeout in 
HugeFileDownloadTest (perhaps the timeout should be increased?)

- Ubuntu 16.04 32bit, OpenJDK 1.8.0_111, Maven 3.3.9: All OK
- Ubuntu 16.04 32bit, OpenJDK 1.7.0_95, Maven 3.3.9: All OK

With Maven 3.4.0-SNAPSHOT (65960ac18c8121648fe163612375a2ba5f4535c2), I 
have compilation errors in the test class FileWagonTest (both on Windows 
and Ubuntu)


[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] 
/home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[37,8]
 cannot access junit.framework.TestCase
  class file for junit.framework.TestCase not found
[ERROR] 
/home/guillaume/workspace-maven/maven-wagon/wagon-providers/wagon-file/src/test/java/org/apache/maven/wagon/providers/file/FileWagonTest.java:[48,52]
 cannot find symbol
  symbol:   method getName()
  location: class org.apache.maven.wagon.providers.file.FileWagonTest

The JUnit dependency isn't getting pulled. This is the scenario at hand:

- wagon-file has as parent wagon-providers which has a dependency on 
wagon-provider-test with scope test.
- wagon-provider-test has a compile scoped dependency on junit 
(compile is explicitly written).
- wagon-provider-test has as parent wagon, which has a test scoped 
dependency management on junit.


What would be the problem?

The tree displayed in the logs when building wagon-provider-test 
correctly lists JUnit with scope compile:


[DEBUG] org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT
[DEBUG]org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]org.codehaus.plexus:plexus-container-default:jar:1.5.5:compile
[DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.2:compile
[DEBUG]   org.apache.xbean:xbean-reflect:jar:3.4:compile
[DEBUG]  log4j:log4j:jar:1.2.12:compile
[DEBUG]  commons-logging:commons-logging-api:jar:1.1:compile
[DEBUG]   com.google.collections:google-collections:jar:1.0:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]org.easymock:easymock:jar:3.2:compile
[DEBUG]   cglib:cglib-nodep:jar:2.2.2:compile
[DEBUG]   org.objenesis:objenesis:jar:1.3:compile
[DEBUG]org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:compile
[DEBUG]   
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:compile
[DEBUG]javax.servlet:javax.servlet-api:jar:3.0.1:compile
[DEBUG]org.slf4j:slf4j-api:jar:1.7.19:compile
[DEBUG]junit:junit:jar:4.11:compile
[DEBUG]   org.hamcrest:hamcrest-core:jar:1.3:compile

But when building wagon-file, the tree is:

[DEBUG] org.apache.maven.wagon:wagon-file:jar:2.12-SNAPSHOT
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.24:compile
[DEBUG]org.slf4j:slf4j-simple:jar:1.7.19:test
[DEBUG]   org.slf4j:slf4j-api:jar:1.7.19:test
[DEBUG]org.apache.maven.wagon:wagon-provider-api:jar:2.12-SNAPSHOT:compile
[DEBUG]org.apache.maven.wagon:wagon-provider-test:jar:2.12-SNAPSHOT:test
[DEBUG]   org.codehaus.plexus:plexus-container-default:jar:1.5.5:test
[DEBUG]  org.codehaus.plexus:plexus-classworlds:jar:2.2.2:test
[DEBUG]  org.apache.xbean:xbean-reflect:jar:3.4:test
[DEBUG] log4j:log4j:jar:1.2.12:test
[DEBUG] commons-logging:commons-logging-api:jar:1.1:test
[DEBUG]  com.google.collections:google-collections:jar:1.0:test
[DEBUG]   org.easymock:easymock:jar:3.2:test
[DEBUG]  cglib:cglib-nodep:jar:2.2.2:test
[DEBUG]  org.objenesis:objenesis:jar:1.3:test
[DEBUG]   org.eclipse.jetty.aggregate:jetty-all:jar:8.1.22.v20160922:test
[DEBUG]  
org.eclipse.jetty.orbit:javax.servlet:jar:3.0.0.v201112011016:test
[DEBUG]   javax.servlet:javax.servlet-api:jar:3.0.1:test


Is the problem that, during resolving the dependencies for wagon-file, 
the compiled scope JUnit dependency of the direct wagon-provider-test 
dependency is getting managed to scope test (due to the parent), and 
therefore that this now test-scoped dependency of wagon-provider-test 
isn't retrieved transitively (because it is a test dependency of a 
direct test dependency)?


Guillaume

Le 28/12/2016 à 12:00, Hervé BOUTEMY a écrit :

the branch runs without issue on my machine now:
mvn: 3.3.9, jdk: Oracle 1.7.0_71, OS: Linux

the proposed release was consistently failing on HugeFileDownloadTest

Notice that with Maven 3.4.0-SNAPSHOT, there is a compilation failure:
testCompile (default-testCompile) on project wagon-file

Using "-ldm" makes the build happy again, until a Surefire run fails with a
timeout...

Regards,

Hervé

Le mercredi 28 décembre 2016, 02:05:23 CET Michael Osipov a écrit :

Hi Dan,

Am 2016-12-25 um 19:51

Re: [VOTE] Releasing Wagon 2.11 - Cancel

2016-12-28 Thread Dan Tran

Hi

I am going to cancel this vote due to inconsistent test failure at
wagon-http provider on huge download test.

Thanks

-Dan

On Wed, Dec 28, 2016 at 7:08 AM, Michael Osipov  wrote:

> Am 2016-12-28 um 06:05 schrieb Dan Tran:
>
>> i still see the same timeout error on the jetty8 branch. No issue at
>> master
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
>> (default-test) on project wagon-http: There was a timeout or other
>> error in the fork -> [Help
>> 1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>> execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
>> (default-test) on project wagon-http: There was a timeout or other
>> error in the fork
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(Moj
>> oExecutor.java:212)
>>
>
> I have now extended tests to other Linux distros:
>
> Fedora 25, 64 bit:
> OpenJDK 8 Update 111: pass
>
> CentOS 7, 64 bit:
> OpenJDK 8 Update 111: pass
> OpenJDK 7 Update 121: pass*
>
> *This is actually your combo which works for me, but not for you...
>
> Additionally, I added this version to Maven 3.4.0-SNAPSHOT and ran ITs on
> Windows 10, Fedora 25 and FreeBSD 10.3-RELEASE. All passed.
>
>
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [1/2] maven-wagon git commit: [WAGON-474] Upgrade and revise all tests for Jetty 8

2016-12-28 Thread Dan Tran

strange, i placed your recommended logger settings
under systemPropertyVariables

and see no log for the timeout issue

Anyway I am going to cancel the vote and have to roll it again

Thanks

-Dan

On Wed, Dec 28, 2016 at 6:18 AM, Michael Osipov  wrote:

> Am 2016-12-28 um 15:07 schrieb Olivier Lamy:
>
>> 2017 is in few days so maybe java 1.7 shouldn't be a big problem
>>
>
> While this is correct, I don't want to change 10 things at once. At last,
> if no one changes the code to 1.7, there won't be any benefit. I'd move
> this for n+1 release.
>
> Michael
>
> On Wed, 28 Dec 2016 at 11:09 am, Michael Osipov 
>> wrote:
>>
>> Am 2016-12-28 um 08:54 schrieb Olivier Lamy:
>>
>> Hi
>>>
>>
>> What about at least Jetty 9.2? (8.x is not anymore supported)
>>>
>>
>>
>>
>> Wagon is still Java 1.6, therefore I had to stick to Jetty 8.
>>
>> Moving from 8 to 9 is easier than from 6 to 9.
>>
>>
>>
>> See:
>>
>> https://www.eclipse.org/jetty/documentation/9.3.x/what-jetty-version.html
>>
>>
>>
>> On 26 December 2016 at 10:58,  wrote:
>>>
>>
>>
>>>
>> Repository: maven-wagon

>>>
>> Updated Branches:

>>>
>>   refs/heads/jetty-8 [created] e707a2691

>>>
>>

>>

>> [WAGON-474] Upgrade and revise all tests for Jetty 8

>>>
>>

>> * Upgrade all test code to Jetty 8.1.22 and Servlet 3.0

>>>
>> * Unify variable names in redirect usecases to realServer and

>>>
>>   redirectServer

>>>
>> * RedirectHandler: redirect code is passed but completely ignored because

>>>
>>   sendRedirect() always sends 302

>>>
>> * Chronologically sort checkHandlerResult() calls

>>>
>> ** Set redirect code (See Other (303)) as requested

>>>
>> ** Update checkHandlerResult() for requested status codes rather sent

>>>
>>chosen by server (mismatched previously)

>>>
>> * testPreemptiveAuthentication*(): properly check for OK for GET and

>>>
>>   CREATED for PUT instead of OK only for both

>>>
>> * WebDavWagonTest: replace status code literal for

>>>
>>   HttpServletResponse.SC_* for better readability

>>>
>> * testRedirect*(): add more checkHandlerResults

>>>
>>

>>

>> Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo

>>>
>> Commit:

>>> http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/2e1c807e
>>
>> Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/2e1c807e

>>>
>> Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/2e1c807e

>>>
>>

>> Branch: refs/heads/jetty-8

>>>
>> Commit: 2e1c807e5345a1999376771f8b378b8cd3328fee

>>>
>> Parents: b451e41

>>>
>> Author: Michael Osipov 

>>>
>> Authored: Mon Dec 26 00:55:09 2016 +0100

>>>
>> Committer: Michael Osipov 

>>>
>> Committed: Mon Dec 26 00:55:09 2016 +0100

>>>
>>

>> --

>>>
>>  pom.xml |  14 +-

>>>
>>  wagon-provider-test/pom.xml |   8 +-

>>>
>>  .../maven/wagon/http/HttpWagonTestCase.java | 273

>>> ++-
>>
>>  wagon-providers/wagon-http-lightweight/pom.xml  |   4 +-

>>>
>>  .../http/LightweightHttpsWagonTest.java |   6 +-

>>>
>>  wagon-providers/wagon-http/pom.xml  |   8 +-

>>>
>>  .../http/HttpWagonHttpServerTestCase.java   |  14 +-

>>>
>>  .../http/HttpWagonReasonPhraseTest.java |   2 +-

>>>
>>  .../providers/http/HttpWagonTimeoutTest.java|   2 +-

>>>
>>  .../http/HttpsWagonPreemptiveTest.java  |   6 +-

>>>
>>  .../wagon/providers/http/HttpsWagonTest.java|   6 +-

>>>
>>  .../providers/http/HugeFileDownloadTest.java|  14 +-

>>>
>>  wagon-providers/wagon-ssh/pom.xml   |   8 +-

>>>
>>  .../ssh/jsch/ScpWagonWithProxyTest.java |  16 +-

>>>
>>  wagon-providers/wagon-webdav-jackrabbit/pom.xml |   8 +-

>>>
>>  .../wagon/providers/webdav/WebDavWagonTest.java |  73 ++---

>>>
>>  .../providers/webdav/WebDavsWagonTest.java  |   6 +-

>>>
>>  wagon-tcks/wagon-tck-http/pom.xml   |  12 +-

>>>
>>  .../wagon/tck/http/fixture/ServerFixture.java   |  52 ++--

>>>
>>  19 files changed, 278 insertions(+), 254 deletions(-)

>>>
>> --

>>>
>>

>>

>> http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/2e1c807e/pom.xml

>>>
>> --

>>>
>> diff --git a/pom.xml b/pom.xml

>>>
>> index e127da4..a90a1ba 100644

>>>
>> --- a/pom.xml

>>>
>> +++ b/pom.xml

>>>
>> @@ -313,14 +313,14 @@ under the License.

>>>
>>

>>>
>>

>>

>>>
>> -org.mortbay.jetty

>>>
>> -

Re: [VOTE] Releasing Wagon 2.11


Am 2016-12-28 um 06:05 schrieb Dan Tran:

i still see the same timeout error on the jetty8 branch. No issue at master

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(default-test) on project wagon-http: There was a timeout or other
error in the fork -> [Help
1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(default-test) on project wagon-http: There was a timeout or other
error in the fork
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)


I have now extended tests to other Linux distros:

Fedora 25, 64 bit:
OpenJDK 8 Update 111: pass

CentOS 7, 64 bit:
OpenJDK 8 Update 111: pass
OpenJDK 7 Update 121: pass*

*This is actually your combo which works for me, but not for you...

Additionally, I added this version to Maven 3.4.0-SNAPSHOT and ran ITs 
on Windows 10, Fedora 25 and FreeBSD 10.3-RELEASE. All passed.



Michael

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

Re: [1/2] maven-wagon git commit: [WAGON-474] Upgrade and revise all tests for Jetty 8


Am 2016-12-28 um 15:07 schrieb Olivier Lamy:

2017 is in few days so maybe java 1.7 shouldn't be a big problem


While this is correct, I don't want to change 10 things at once. At 
last, if no one changes the code to 1.7, there won't be any benefit. I'd 
move this for n+1 release.


Michael


On Wed, 28 Dec 2016 at 11:09 am, Michael Osipov  wrote:

Am 2016-12-28 um 08:54 schrieb Olivier Lamy:


Hi



What about at least Jetty 9.2? (8.x is not anymore supported)




Wagon is still Java 1.6, therefore I had to stick to Jetty 8.

Moving from 8 to 9 is easier than from 6 to 9.



See:

https://www.eclipse.org/jetty/documentation/9.3.x/what-jetty-version.html




On 26 December 2016 at 10:58,  wrote:







Repository: maven-wagon



Updated Branches:



  refs/heads/jetty-8 [created] e707a2691











[WAGON-474] Upgrade and revise all tests for Jetty 8







* Upgrade all test code to Jetty 8.1.22 and Servlet 3.0



* Unify variable names in redirect usecases to realServer and



  redirectServer



* RedirectHandler: redirect code is passed but completely ignored because



  sendRedirect() always sends 302



* Chronologically sort checkHandlerResult() calls



** Set redirect code (See Other (303)) as requested



** Update checkHandlerResult() for requested status codes rather sent



   chosen by server (mismatched previously)



* testPreemptiveAuthentication*(): properly check for OK for GET and



  CREATED for PUT instead of OK only for both



* WebDavWagonTest: replace status code literal for



  HttpServletResponse.SC_* for better readability



* testRedirect*(): add more checkHandlerResults











Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo



Commit:

http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/2e1c807e


Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/2e1c807e



Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/2e1c807e







Branch: refs/heads/jetty-8



Commit: 2e1c807e5345a1999376771f8b378b8cd3328fee



Parents: b451e41



Author: Michael Osipov 



Authored: Mon Dec 26 00:55:09 2016 +0100



Committer: Michael Osipov 



Committed: Mon Dec 26 00:55:09 2016 +0100







--



 pom.xml |  14 +-



 wagon-provider-test/pom.xml |   8 +-



 .../maven/wagon/http/HttpWagonTestCase.java | 273

++-


 wagon-providers/wagon-http-lightweight/pom.xml  |   4 +-



 .../http/LightweightHttpsWagonTest.java |   6 +-



 wagon-providers/wagon-http/pom.xml  |   8 +-



 .../http/HttpWagonHttpServerTestCase.java   |  14 +-



 .../http/HttpWagonReasonPhraseTest.java |   2 +-



 .../providers/http/HttpWagonTimeoutTest.java|   2 +-



 .../http/HttpsWagonPreemptiveTest.java  |   6 +-



 .../wagon/providers/http/HttpsWagonTest.java|   6 +-



 .../providers/http/HugeFileDownloadTest.java|  14 +-



 wagon-providers/wagon-ssh/pom.xml   |   8 +-



 .../ssh/jsch/ScpWagonWithProxyTest.java |  16 +-



 wagon-providers/wagon-webdav-jackrabbit/pom.xml |   8 +-



 .../wagon/providers/webdav/WebDavWagonTest.java |  73 ++---



 .../providers/webdav/WebDavsWagonTest.java  |   6 +-



 wagon-tcks/wagon-tck-http/pom.xml   |  12 +-



 .../wagon/tck/http/fixture/ServerFixture.java   |  52 ++--



 19 files changed, 278 insertions(+), 254 deletions(-)



--











http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/2e1c807e/pom.xml



--



diff --git a/pom.xml b/pom.xml



index e127da4..a90a1ba 100644



--- a/pom.xml



+++ b/pom.xml



@@ -313,14 +313,14 @@ under the License.



   







   



-org.mortbay.jetty



-jetty



-6.1.26



+org.eclipse.jetty.aggregate



+jetty-all



+8.1.22.v20160922



   



   



-org.mortbay.jetty



-servlet-api



-2.5-20081211



+javax.servlet



+javax.servlet-api



+3.0.1



 



 



   



@@ -565,5 +565,5 @@ under the License.



   



 



   



-



+



 







http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/



2e1c807e/wagon-provider-test/pom.xml



--



diff --git a/wagon-provider-test/pom.xml b/wagon-provider-test/pom.xml



index b19e7ac..9b0f4e5 100644



--- a/wagon-provider-test/pom.xml



+++ b/wagon-provider-test/pom.xml



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



   compile



 



 



-  org.mortbay.jetty



-  jetty



+  org.eclipse.jetty.aggregate



+  jetty-all

Re: [1/2] maven-wagon git commit: [WAGON-474] Upgrade and revise all tests for Jetty 8

2016-12-28 Thread Olivier Lamy

2017 is in few days so maybe java 1.7 shouldn't be a big problem

On Wed, 28 Dec 2016 at 11:09 am, Michael Osipov  wrote:

Am 2016-12-28 um 08:54 schrieb Olivier Lamy:

> Hi

> What about at least Jetty 9.2? (8.x is not anymore supported)



Wagon is still Java 1.6, therefore I had to stick to Jetty 8.

Moving from 8 to 9 is easier than from 6 to 9.



See:

https://www.eclipse.org/jetty/documentation/9.3.x/what-jetty-version.html



> On 26 December 2016 at 10:58,  wrote:

>

>> Repository: maven-wagon

>> Updated Branches:

>>   refs/heads/jetty-8 [created] e707a2691

>>

>>

>> [WAGON-474] Upgrade and revise all tests for Jetty 8

>>

>> * Upgrade all test code to Jetty 8.1.22 and Servlet 3.0

>> * Unify variable names in redirect usecases to realServer and

>>   redirectServer

>> * RedirectHandler: redirect code is passed but completely ignored because

>>   sendRedirect() always sends 302

>> * Chronologically sort checkHandlerResult() calls

>> ** Set redirect code (See Other (303)) as requested

>> ** Update checkHandlerResult() for requested status codes rather sent

>>chosen by server (mismatched previously)

>> * testPreemptiveAuthentication*(): properly check for OK for GET and

>>   CREATED for PUT instead of OK only for both

>> * WebDavWagonTest: replace status code literal for

>>   HttpServletResponse.SC_* for better readability

>> * testRedirect*(): add more checkHandlerResults

>>

>>

>> Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo

>> Commit:
http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/2e1c807e

>> Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/2e1c807e

>> Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/2e1c807e

>>

>> Branch: refs/heads/jetty-8

>> Commit: 2e1c807e5345a1999376771f8b378b8cd3328fee

>> Parents: b451e41

>> Author: Michael Osipov 

>> Authored: Mon Dec 26 00:55:09 2016 +0100

>> Committer: Michael Osipov 

>> Committed: Mon Dec 26 00:55:09 2016 +0100

>>

>> --

>>  pom.xml |  14 +-

>>  wagon-provider-test/pom.xml |   8 +-

>>  .../maven/wagon/http/HttpWagonTestCase.java | 273
++-

>>  wagon-providers/wagon-http-lightweight/pom.xml  |   4 +-

>>  .../http/LightweightHttpsWagonTest.java |   6 +-

>>  wagon-providers/wagon-http/pom.xml  |   8 +-

>>  .../http/HttpWagonHttpServerTestCase.java   |  14 +-

>>  .../http/HttpWagonReasonPhraseTest.java |   2 +-

>>  .../providers/http/HttpWagonTimeoutTest.java|   2 +-

>>  .../http/HttpsWagonPreemptiveTest.java  |   6 +-

>>  .../wagon/providers/http/HttpsWagonTest.java|   6 +-

>>  .../providers/http/HugeFileDownloadTest.java|  14 +-

>>  wagon-providers/wagon-ssh/pom.xml   |   8 +-

>>  .../ssh/jsch/ScpWagonWithProxyTest.java |  16 +-

>>  wagon-providers/wagon-webdav-jackrabbit/pom.xml |   8 +-

>>  .../wagon/providers/webdav/WebDavWagonTest.java |  73 ++---

>>  .../providers/webdav/WebDavsWagonTest.java  |   6 +-

>>  wagon-tcks/wagon-tck-http/pom.xml   |  12 +-

>>  .../wagon/tck/http/fixture/ServerFixture.java   |  52 ++--

>>  19 files changed, 278 insertions(+), 254 deletions(-)

>> --

>>

>>

>> http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/2e1c807e/pom.xml

>> --

>> diff --git a/pom.xml b/pom.xml

>> index e127da4..a90a1ba 100644

>> --- a/pom.xml

>> +++ b/pom.xml

>> @@ -313,14 +313,14 @@ under the License.

>>

>>

>>

>> -org.mortbay.jetty

>> -jetty

>> -6.1.26

>> +org.eclipse.jetty.aggregate

>> +jetty-all

>> +8.1.22.v20160922

>>

>>

>> -org.mortbay.jetty

>> -servlet-api

>> -2.5-20081211

>> +javax.servlet

>> +javax.servlet-api

>> +3.0.1

>>  

>>  

>>

>> @@ -565,5 +565,5 @@ under the License.

>>

>>  

>>

>> -

>> +

>>  

>>

>> http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/

>> 2e1c807e/wagon-provider-test/pom.xml

>> --

>> diff --git a/wagon-provider-test/pom.xml b/wagon-provider-test/pom.xml

>> index b19e7ac..9b0f4e5 100644

>> --- a/wagon-provider-test/pom.xml

>> +++ b/wagon-provider-test/pom.xml

>> @@ -51,12 +51,12 @@ under the License.

>>compile

>>  

>>  

>> -  org.mortbay.jetty

>> -  jetty

>> +  org.eclipse.jetty.aggregate

>> +  jetty-all

>>  

>>  

>> -  org.mortbay.jetty

>> -  servlet-api

>> +  javax.servlet

>> +  javax.servlet-api

>>  

>>  

>>

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

2016-12-28 Thread Robert Scholte

On Wed, 28 Dec 2016 11:47:40 +0100, Hervé BOUTEMY   
wrote:

Le mardi 27 décembre 2016, 14:48:56 CET Robert Scholte a écrit :
>> The fact right now is that if I add/change a test-scoped dependency,  
it

>> could happen that the project won't run due to a missing transitive
>> dependency.
>> We are very, very lucky this doesn't happen that often.
>
> This is what would stop if we would just fix those bugs. We are  
running
> into those bugs ourselves. Take a look at the PMD plugin POM again.  
What

> would you have done, if the test dependencies I moved to compile scope
> would be required for compilation of that project?

With the current behavior I wouldn't include these dependencies at all,
since they're already available as compile-scoped transitive dependency.
When due to an upgrade of a dependency commons-io is not used anymore,
tests will fail to compile. And that's the moment to add this  
dependency.

IMO changing dependencies should never cause compilation failures caused
by transitive dependencies, but right now there's simply no better
solution. We say that it is a best practice to always define the direct
dependencies, but in this case we can't do that because we cannot give
these dependencies the test-scope.

notice that this seems to have been reported years ago:
https://issues.apache.org/jira/browse/MNG-5739

and IMHO, if this case was fixed (which seems reasonable), MNG-6135  
would not
break so many plugins (which do not have really broken config: having to  
avoid
a test scope dependency just because it will override a transitive  
compile
dependency is just the trial and error configuration people will have to  
do)

You fully hit the nail. Before MNG-6135 the resolution was working as  
expected, even though it may seem as a very simplified dependency  
resolution: only look at direct compile+runtime -scoped dependencies and  
their transitive deps. In fact, I like this concept in general: pick all  
direct dependencies matching one or more scopes and all their transitive  
dependencies.
To me there are 2 solutions: either implement MNG-5739 or revert MNG-6135.  
Any of both solutions will make plugins again run as expected.

Robert

Regards,

Hervé

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

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

Re: [VOTE] Releasing Wagon 2.11

the branch runs without issue on my machine now:
mvn: 3.3.9, jdk: Oracle 1.7.0_71, OS: Linux

the proposed release was consistently failing on HugeFileDownloadTest

Notice that with Maven 3.4.0-SNAPSHOT, there is a compilation failure:
testCompile (default-testCompile) on project wagon-file

Using "-ldm" makes the build happy again, until a Surefire run fails with a 
timeout...

Regards,

Hervé

Le mercredi 28 décembre 2016, 02:05:23 CET Michael Osipov a écrit :
> Hi Dan,
> 
> Am 2016-12-25 um 19:51 schrieb Dan Tran:
> > Just want to confirm,  your FreeBSD and build.apache.org's ubuntu see the
> > same test failure??
> > 
> > Do you think we should cancel the vote and wait for your fix?
> 
> I was finally able to complete my coding and testings. After several
> hours of testing and debugging, I've found the reasons why several tests
> were failing sporadically, some were bad test conditions
> (testSecuredGet(), testSecuredGetToStream()) and some rooted in bugs in
> HttpWagon. I'll go in detail:
> 
> 1. Flaky testSecuredGet(ToStream):
> This failed once in a while due to race conditions between Jetty's qtp
> threads and the main thread running the tests and the assertions. Jetty
> did not fully complete the process chain while Surefire continued to
> verify the result. This yielded to: expected <2> requests found <1> and
> so forth. I added a simple sleep() and it did work. I avoided to have
> complex sync code with CountDownLatch or alike. Some logging added to
> 
> the code shows the following in Surefire's XML output:
> >  > type="junit.framework.AssertionFailedError">
> 
> now the logging:
> > 
> 
> now take a look at TestSecurityHandler output. I added it after
> super.handle() called by Jetty. As you can see,
> "org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
> (1)" is printed where the assertions kick in, after Wagon has completed,
> but the second request is handled afterwards. A traditional race condition.
> 
> 2. Bugs found:
> Several auth tests fail for no reason too once in a while. Logging
> showed me that HttpClient simply did not send any Basic data, regardless
> if preemptive or after a roundtrip. The basic problem was that
> non-threadsafe classes have been used in a non-threadsafe manner as well
> as auth caches have not beed released properly, and preemptive auth was
> configured incorrectly. After fixing the issues one by one, the tests
> never failed again.
> 
> I have tested the code on three platforms and six JDK versions tens of
> times, they never failed again. After we have resolved your
> HugeDowloadTest issue and no one else objects, I'd like to merge this
> into master and like you to reroll 2.11 with those changes.
> 
> Meanwhile, I'll test this branch with Maven Core IT Suite too.
> 
> Michael
> 
> -
> 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

Le mardi 27 décembre 2016, 14:48:56 CET Robert Scholte a écrit :
> >> The fact right now is that if I add/change a test-scoped dependency, it
> >> could happen that the project won't run due to a missing transitive
> >> dependency.
> >> We are very, very lucky this doesn't happen that often.
> > 
> > This is what would stop if we would just fix those bugs. We are running
> > into those bugs ourselves. Take a look at the PMD plugin POM again. What
> > would you have done, if the test dependencies I moved to compile scope
> > would be required for compilation of that project?
> 
> With the current behavior I wouldn't include these dependencies at all,
> since they're already available as compile-scoped transitive dependency.
> When due to an upgrade of a dependency commons-io is not used anymore,
> tests will fail to compile. And that's the moment to add this dependency.
> IMO changing dependencies should never cause compilation failures caused
> by transitive dependencies, but right now there's simply no better
> solution. We say that it is a best practice to always define the direct
> dependencies, but in this case we can't do that because we cannot give
> these dependencies the test-scope.
notice that this seems to have been reported years ago:
https://issues.apache.org/jira/browse/MNG-5739

and IMHO, if this case was fixed (which seems reasonable), MNG-6135 would not 
break so many plugins (which do not have really broken config: having to avoid 
a test scope dependency just because it will override a transitive compile 
dependency is just the trial and error configuration people will have to do)

Regards,

Hervé

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

Re: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

2016-12-28 Thread Robert Scholte


So can we remove the commandline option?

And anything we cannot agree on push to Model 5.0.0? This way model 4.0.0  
works as it did (apart from the real bugfixes) and we can finally start  
making milestones for M3.4.0
For 5.0.0 we need to reach out to other third parties anyway, so let's  
take that opportunity to do it correct.


Robert

On Mon, 26 Dec 2016 22:42:39 +0100, Christian Schulte   
wrote:



Am 12/26/16 um 21:07 schrieb Stephen Connolly:

Well a command line switch is useless imho.


+1



Suppose I have a multi-module reactor and one module uses version A of
plugin X and another module uses version B.

Now A was built against Maven 3.3.3 and the classpath was "fixed" with
tweaks and hacks to ensure the transitive dependencies worked out  
correctly

(yes they should have filed a bug rather than work around, but life)

B was built against Maven 3.4.0 and all the hacks were removed.

How can we build that reactor with a command line switch? We cannot. The
CLI switch would force with A or B to be wrong.


+1

Same for dependencies.



We need something that works the way users expect *without* requiring  
that

they change their poms


That'd be the best we can do.


This is not something that the user should be able to control directly
IMHO. Adding knobs to tweak the behaviour just complicates things for  
users.


+1

When deployed, no one knows what knobs had been in effect during
deployment. Bad idea. Information must be retained in the POMs.
Prerequisites to the rescue.

We should look at the prerequisites of the plugin and give it the  
correct
classpath for that Maven version (and eg this could include adding in  
Maven
compat for anything pre-3.4.0, aether shims, sonatype shims, etc,  
mapping

plexus utils etc)


+1

I just ran various tests against maven-pmd-plugin version 2.3. That
version can still be used with Maven 2.0 and that version is the first
version introducing an issue where a test artifact overrides a compile
artifact.

With Maven 2.0.11 and 2.2.1 the runtime classpath seems to be equal to
what 3.4.0-SNAPSHOT currently does (test scope dependencies not
available at runtime). This is from the Maven 2.2.1 debug messages:

 org.apache.maven:maven-artifact:jar:2.0:test (*not setting scope to:
compile; local scope test wins*)
org.apache.maven:maven-artifact:jar:2.0:test (*selected for test*)

MRESOLVER-8 seems to be a Maven 3 regression that went unnoticed. This
is something I would not have expected myself.


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


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

Re: [VOTE] Releasing Wagon 2.11

Am 2016-12-28 um 06:05 schrieb Dan Tran:

i still see the same timeout error on the jetty8 branch. No issue at master

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(default-test) on project wagon-http: There was a timeout or other
error in the fork -> [Help
1]org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(default-test) on project wagon-http: There was a timeout or other
error in the fork
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)

I still would like to see your Surefire XML. Please provide! Can you
raise forkedProcessTimeoutInSeconds?
This could also be a race condition where one thread does not wait for
another. Please also note:
https://mail-archives.apache.org/mod_mbox/maven-dev/201612.mbox/%3C81e68f7b-b68f-ce5d-2529-12d604d42c98%40apache.org%3E

Can you set up a job on Jenkins for this branch? I'd like to see wether
the Ubuntu slave fails too.

> It is your call now. since I cant release it

Do you want me to roll the release?

On Tue, Dec 27, 2016 at 5:05 PM, Michael Osipov wrote:

Hi Dan,

Am 2016-12-25 um 19:51 schrieb Dan Tran:

Just want to confirm, your FreeBSD and build.apache.org's ubuntu see the
same test failure??

Do you think we should cancel the vote and wait for your fix?

I was finally able to complete my coding and testings. After several hours
of testing and debugging, I've found the reasons why several tests were
failing sporadically, some were bad test conditions (testSecuredGet(),
testSecuredGetToStream()) and some rooted in bugs in HttpWagon. I'll go in
detail:

1. Flaky testSecuredGet(ToStream):
This failed once in a while due to race conditions between Jetty's qtp
threads and the main thread running the tests and the assertions. Jetty did
not fully complete the process chain while Surefire continued to verify the
result. This yielded to: expected <2> requests found <1> and so forth. I
added a simple sleep() and it did work. I avoided to have complex sync code
with CountDownLatch or alike. Some logging added to the code shows the
following in Surefire's XML output:

responseCode=401, requestUri=/test-secured-resource}]
expected:2 but was:1" type="junit.framework.Assertio
nFailedError">

now the logging:

now take a look at TestSecurityHandler output. I added it after
super.handle() called by Jetty. As you can see,
"org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler@9187167
(1)" is printed where the assertions kick in, after Wagon has completed,
but the second request is handled afterwards. A traditional race condition.

2. Bugs found:
Several auth tests fail for no reason too once in a while. Logging showed
me that HttpClient simply did not send any Basic data, regardless if
preemptive or after a roundtrip. The basic problem was that non-threadsafe
classes have been used in a non-threadsafe manner as well as auth caches
have not beed released properly, and preemptive auth was configured
incorrectly. After fixing the issues one by one, the tests never failed
again.

I have tested the code on three platforms and six JDK versions tens of
times, they never failed again. After we have resolved your HugeDowloadTest
issue and no one else objects, I'd like to merge this into master and like
you to reroll 2.11 with those changes.

Meanwhile, I'll test this branch with Maven Core IT Suite too.

Michael

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

Re: [1/2] maven-wagon git commit: [WAGON-474] Upgrade and revise all tests for Jetty 8