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

[Dan Tran]

redhat7/openjdk 7 ( latest)

this test fails on timeout.  I have seen this issue before not lately. Used
to work on  2.9, 2 10, and 2.11)

-D

On Sun, Dec 25, 2016 at 4:59 PM, Michael Osipov  wrote:

> Am 2016-12-26 um 01:45 schrieb Dan Tran:
>
>> this branch has one test consistently fail test on my local redhat 7,
>> java 7
>>
>> Running org.apache.maven.wagon.providers.http.HugeFileDownloadTest
>>
>
> What does it say? What JDK version do you use?
>
> This test works for me on two operating systems and five JDK versions.
>
>
> -
> 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

[Michael Osipov]

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??


As you have already noticed, the branch is up. It is preliminary work, 
but should be quite complete.


The runTestSecuredGet() and friends failures might be due to:

[main] INFO org.eclipse.jetty.server.handler.ContextHandler - stopped 
o.e.j.s.ServletContextHandler{/,file:/usr/home/mosipov/Projekte/maven-wagon/wagon-providers/wagon-http/target/test-output/}
[qtp1948835427-2572] WARN org.eclipse.jetty.server.Response - Committed before 
500 org.eclipse.jetty.io.EofException
[qtp1948835427-2572] WARN org.eclipse.jetty.server.AbstractHttpConnection - 
/test-secured-resource
java.lang.IllegalStateException: Committed
at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1145)
at org.eclipse.jetty.server.Response.sendError(Response.java:315)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:566)
at 
org.apache.maven.wagon.http.HttpWagonTestCase$TestSecurityHandler.handle(HttpWagonTestCase.java:2148)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:973)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1035)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:641)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:231)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at 
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at 
org.eclipse.jetty.server.ssl.SslSocketConnector$SslConnectorEndPoint.run(SslSocketConnector.java:670)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)


I have them sporadically. According to Stackoverflow, the client closes 
the connection in flight, the server does not expect that and fails. 
Though the Java code is the same, it might be related to different 
socket approaches in Windows and Linux/FreeBSD.


Jetty's BasicAuthenticator sends 401 which fails with IOExeption, 
SecurityHandler catches and sends 500 which fails again. This is clearly 
a socket issue for me.

This requires tweaking the HttpClientConnectionManager.


-
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

[Michael Osipov]

Am 2016-12-26 um 01:45 schrieb Dan Tran:

this branch has one test consistently fail test on my local redhat 7, java 7

Running org.apache.maven.wagon.providers.http.HugeFileDownloadTest


What does it say? What JDK version do you use?

This test works for me on two operating systems and five JDK versions.


-
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

[Dan Tran]

this branch has one test consistently fail test on my local redhat 7, java 7

Running org.apache.maven.wagon.providers.http.HugeFileDownloadTest




On Sun, Dec 25, 2016 at 3:58 PM,  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
>  
>  
>org.slf4j
>
> http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/
> 2e1c807e/wagon-provider-test/src/main/java/org/apache/maven/wagon/http/
> HttpWagonTestCase.java
> --
> 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 dfc499e..cf479fd 100644
> --- a/wagon-provider-test/src/main/java/org/apache/maven/
> 

Re: [VOTE] Releasing Wagon 2.11

[Michael Osipov]

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??


Yes, I had always the same two build failures as the Ubuntu box in 
contrast to Windows.
I am currently testing the same code on different JDKs also to see 
wether this is a JDK issue or test test setup issue.


Windows 10 Pro, 64 bit:
* Oracle JDK 7 Update 80: pass
* Oracle JDK 8 Update 112: pass (1)
* OpenJDK 7 (Azul Zulu) Update 121: pass

FreeBSD 10.3-RELEASE-p11, 64 bit:
* OpenJDK 7 Update 111: pass
* OpenJDK 8 Update 112: pass

All ran with Maven 3.3.9.

(1) Some HTTP Provider (preemptive) tests are flaky, I do not know why 
yet, strangely they always pass when run from inside Eclipse.



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


We could, yes. This would also include other bugfixes in the code, 
especially with HTTP PUT.


I'll try to push a feature branch on this today and will have you a look 
at it. If this is fine, we can merge into master and reroll the vote.


Michael


On Sun, Dec 25, 2016 at 10:34 AM, Michael Osipov 
wrote:


Am 2016-12-25 um 18:45 schrieb Dan Tran:


Thank Michael

  * Test failures at windows are intermittent.  It is a known issue since
the last few versions
  * No issue at my local redhat 7/java7 build
  * I am seeing test failures at
https://builds.apache.org/view/All/job/maven-wagon/1323/starting with
your change for WAGON-472. Dont think it is related, could be from build
env



This is build env. I have tested Wagon on Windows and FreeBSD before any
patching. Windows was fine, FreeBSD failed for those two cases. It also
passed on Windows with OpenJDK 7 Update 121 from Azul Systems. Though, I
have good news: I have been working on the unit tests in genereal the last
two days by migrating to Jetty 8 (last Java 1.6 supported) version and
found several bugs in Wagon HTTP Provider and the unit test setup itself. I
will report them shortly.

Michael


On Sat, Dec 24, 2016 at 5:07 AM, Michael Osipov 

wrote:

Am 2016-12-24 um 04:07 schrieb Dan Tran:


Hi,


We have fixed 18 issues:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
ectId=12318122=1296
*

There are still issues left in JIRA:
*https://issues.apache.org/jira/issues/?jql=project%20%3D%
20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
20created%20DESC%2C%20priority%20DESC
*

Staging repository:
https://repository.apache.org/content/repositories/maven-1313
https://repository.apache.org/content/repositories/maven-
1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip

Source release checksum(s):
wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a620
00c58abfa5

Staging site:
*http://maven.apache.org/components/wagon-archives/wagon-LATEST/
*

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72H + 48H to accomodate for holidays



+1

SHA1 is fine, site is fine. Builds passes on Windows but constantly fails
on non-Windows, here on my FreeBSD machine as well as on our Jenkins
Ubuntu
slave. It should probably investigated for the 3.0 release.

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







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

Re: maven-wagon git commit: [WAGON-471] Clean up dependency mess (reported by dependency:analyze)

[Michael Osipov]

Am 2016-12-25 um 21:34 schrieb Dan Tran:

is it necessary to introduce


 org.slf4j
 slf4j-simple
 

as compile scope?


It is not in compile scope. Please have a look into dependencyManagement 
in parent. The default scope for this dependency is test:

https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=blob;f=pom.xml;h=e127da4bec14c4312511e7d74b935551da5e5fa6;hb=HEAD#l291


On Sun, Dec 25, 2016 at 12:10 PM,  wrote:


Repository: maven-wagon
Updated Branches:
  refs/heads/master 4da2accfd -> b451e418e


[WAGON-471] Clean up dependency mess (reported by dependency:analyze)

Followup fix for SLF4J Simple in test scope for file, scm and
http-lightweight.


Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/b451e418
Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/b451e418
Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/b451e418

Branch: refs/heads/master
Commit: b451e418ed5235f231f5288fd21054f450669aa9
Parents: 4da2acc
Author: Michael Osipov 
Authored: Sun Dec 25 21:09:43 2016 +0100
Committer: Michael Osipov 
Committed: Sun Dec 25 21:09:43 2016 +0100

--
 wagon-providers/wagon-file/pom.xml | 4 
 wagon-providers/wagon-http-lightweight/pom.xml | 4 
 wagon-providers/wagon-scm/pom.xml  | 4 
 3 files changed, 12 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/
b451e418/wagon-providers/wagon-file/pom.xml
--
diff --git a/wagon-providers/wagon-file/pom.xml
b/wagon-providers/wagon-file/pom.xml
index 4e3cb52..a96af63 100644
--- a/wagon-providers/wagon-file/pom.xml
+++ b/wagon-providers/wagon-file/pom.xml
@@ -38,5 +38,9 @@ under the License.
   org.codehaus.plexus
   plexus-utils
 
+
+  org.slf4j
+  slf4j-simple
+
   
 

http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/
b451e418/wagon-providers/wagon-http-lightweight/pom.xml
--
diff --git a/wagon-providers/wagon-http-lightweight/pom.xml
b/wagon-providers/wagon-http-lightweight/pom.xml
index 9a0e8c8..f723004 100644
--- a/wagon-providers/wagon-http-lightweight/pom.xml
+++ b/wagon-providers/wagon-http-lightweight/pom.xml
@@ -64,5 +64,9 @@ under the License.
   jetty
   test
 
+
+  org.slf4j
+  slf4j-simple
+
   
 

http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/
b451e418/wagon-providers/wagon-scm/pom.xml
--
diff --git a/wagon-providers/wagon-scm/pom.xml
b/wagon-providers/wagon-scm/pom.xml
index 55c14e6..881040a 100644
--- a/wagon-providers/wagon-scm/pom.xml
+++ b/wagon-providers/wagon-scm/pom.xml
@@ -65,6 +65,10 @@ under the License.
   ${mavenScmVersion}
   test
 
+
+  org.slf4j
+  slf4j-simple
+
   

   







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

Re: maven-wagon git commit: [WAGON-471] Clean up dependency mess (reported by dependency:analyze)

[Dan Tran]

is it necessary to introduce


 org.slf4j
 slf4j-simple
 

as compile scope?

Thanks

-Dan

On Sun, Dec 25, 2016 at 12:10 PM,  wrote:

> Repository: maven-wagon
> Updated Branches:
>   refs/heads/master 4da2accfd -> b451e418e
>
>
> [WAGON-471] Clean up dependency mess (reported by dependency:analyze)
>
> Followup fix for SLF4J Simple in test scope for file, scm and
> http-lightweight.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven-wagon/repo
> Commit: http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/b451e418
> Tree: http://git-wip-us.apache.org/repos/asf/maven-wagon/tree/b451e418
> Diff: http://git-wip-us.apache.org/repos/asf/maven-wagon/diff/b451e418
>
> Branch: refs/heads/master
> Commit: b451e418ed5235f231f5288fd21054f450669aa9
> Parents: 4da2acc
> Author: Michael Osipov 
> Authored: Sun Dec 25 21:09:43 2016 +0100
> Committer: Michael Osipov 
> Committed: Sun Dec 25 21:09:43 2016 +0100
>
> --
>  wagon-providers/wagon-file/pom.xml | 4 
>  wagon-providers/wagon-http-lightweight/pom.xml | 4 
>  wagon-providers/wagon-scm/pom.xml  | 4 
>  3 files changed, 12 insertions(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/
> b451e418/wagon-providers/wagon-file/pom.xml
> --
> diff --git a/wagon-providers/wagon-file/pom.xml
> b/wagon-providers/wagon-file/pom.xml
> index 4e3cb52..a96af63 100644
> --- a/wagon-providers/wagon-file/pom.xml
> +++ b/wagon-providers/wagon-file/pom.xml
> @@ -38,5 +38,9 @@ under the License.
>org.codehaus.plexus
>plexus-utils
>  
> +
> +  org.slf4j
> +  slf4j-simple
> +
>
>  
>
> http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/
> b451e418/wagon-providers/wagon-http-lightweight/pom.xml
> --
> diff --git a/wagon-providers/wagon-http-lightweight/pom.xml
> b/wagon-providers/wagon-http-lightweight/pom.xml
> index 9a0e8c8..f723004 100644
> --- a/wagon-providers/wagon-http-lightweight/pom.xml
> +++ b/wagon-providers/wagon-http-lightweight/pom.xml
> @@ -64,5 +64,9 @@ under the License.
>jetty
>test
>  
> +
> +  org.slf4j
> +  slf4j-simple
> +
>
>  
>
> http://git-wip-us.apache.org/repos/asf/maven-wagon/blob/
> b451e418/wagon-providers/wagon-scm/pom.xml
> --
> diff --git a/wagon-providers/wagon-scm/pom.xml
> b/wagon-providers/wagon-scm/pom.xml
> index 55c14e6..881040a 100644
> --- a/wagon-providers/wagon-scm/pom.xml
> +++ b/wagon-providers/wagon-scm/pom.xml
> @@ -65,6 +65,10 @@ under the License.
>${mavenScmVersion}
>test
>  
> +
> +  org.slf4j
> +  slf4j-simple
> +
>
>
>
>
>

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

[Christian Schulte]

To stop my confusion from slipping onto others:

Whenever I talked about project vs. dependency resolution, just forget
about that to be different. That's the result of my confusion during
working on MRESOLVER-8. There is no difference. There should be no
difference. There had been a difference due to MRESOLVER-8. Period.

If you take a look at the example, there is a difference in resolution
of module-3 vs. module-4. I am really talking about that difference.


-
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

[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?

Thanks

-Dan

On Sun, Dec 25, 2016 at 10:34 AM, Michael Osipov 
wrote:

> Am 2016-12-25 um 18:45 schrieb Dan Tran:
>
>> Thank Michael
>>
>>   * Test failures at windows are intermittent.  It is a known issue since
>> the last few versions
>>   * No issue at my local redhat 7/java7 build
>>   * I am seeing test failures at
>> https://builds.apache.org/view/All/job/maven-wagon/1323/starting with
>> your change for WAGON-472. Dont think it is related, could be from build
>> env
>>
>
> This is build env. I have tested Wagon on Windows and FreeBSD before any
> patching. Windows was fine, FreeBSD failed for those two cases. It also
> passed on Windows with OpenJDK 7 Update 121 from Azul Systems. Though, I
> have good news: I have been working on the unit tests in genereal the last
> two days by migrating to Jetty 8 (last Java 1.6 supported) version and
> found several bugs in Wagon HTTP Provider and the unit test setup itself. I
> will report them shortly.
>
> Michael
>
>
> On Sat, Dec 24, 2016 at 5:07 AM, Michael Osipov 
>> wrote:
>>
>> Am 2016-12-24 um 04:07 schrieb Dan Tran:
>>>
>>> Hi,

 We have fixed 18 issues:
 *https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
 ectId=12318122=1296
 *

 There are still issues left in JIRA:
 *https://issues.apache.org/jira/issues/?jql=project%20%3D%
 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
 20created%20DESC%2C%20priority%20DESC
 *

 Staging repository:
 https://repository.apache.org/content/repositories/maven-1313
 https://repository.apache.org/content/repositories/maven-
 1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip

 Source release checksum(s):
 wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a620
 00c58abfa5

 Staging site:
 *http://maven.apache.org/components/wagon-archives/wagon-LATEST/
 *

 Guide to testing staged releases:
 https://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72H + 48H to accomodate for holidays


>>> +1
>>>
>>> SHA1 is fine, site is fine. Builds passes on Windows but constantly fails
>>> on non-Windows, here on my FreeBSD machine as well as on our Jenkins
>>> Ubuntu
>>> slave. It should probably investigated for the 3.0 release.
>>>
>>> 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: [VOTE] Releasing Wagon 2.11

[Michael Osipov]

Am 2016-12-25 um 18:45 schrieb Dan Tran:

Thank Michael

  * Test failures at windows are intermittent.  It is a known issue since
the last few versions
  * No issue at my local redhat 7/java7 build
  * I am seeing test failures at
https://builds.apache.org/view/All/job/maven-wagon/1323/starting with
your change for WAGON-472. Dont think it is related, could be from build env


This is build env. I have tested Wagon on Windows and FreeBSD before any 
patching. Windows was fine, FreeBSD failed for those two cases. It also 
passed on Windows with OpenJDK 7 Update 121 from Azul Systems. Though, I 
have good news: I have been working on the unit tests in genereal the 
last two days by migrating to Jetty 8 (last Java 1.6 supported) version 
and found several bugs in Wagon HTTP Provider and the unit test setup 
itself. I will report them shortly.


Michael


On Sat, Dec 24, 2016 at 5:07 AM, Michael Osipov  wrote:


Am 2016-12-24 um 04:07 schrieb Dan Tran:


Hi,

We have fixed 18 issues:
*https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
ectId=12318122=1296
*

There are still issues left in JIRA:
*https://issues.apache.org/jira/issues/?jql=project%20%3D%
20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
20created%20DESC%2C%20priority%20DESC
*

Staging repository:
https://repository.apache.org/content/repositories/maven-1313
https://repository.apache.org/content/repositories/maven-
1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip

Source release checksum(s):
wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a620
00c58abfa5

Staging site:
*http://maven.apache.org/components/wagon-archives/wagon-LATEST/
*

Guide to testing staged releases:
https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72H + 48H to accomodate for holidays



+1

SHA1 is fine, site is fine. Builds passes on Windows but constantly fails
on non-Windows, here on my FreeBSD machine as well as on our Jenkins Ubuntu
slave. It should probably investigated for the 3.0 release.

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

[Christian Schulte]

>From what I can tell, the resolver now behaves exactly as the API
Javadoc states it should. I've also written various test cases for the
resolver testing the documented behaviour. From the resolver point of
view, MRESOLVER-8 and MRESOLVER-9 and MRESOLVER-10 are really "just"
bugfixes. How that manifests in Maven is another story. Looking at all
this (again and again and again) is confusing. Mostly because things you
are used to know how they behave change in a way no-one is used to. The
resolver currently really does what it's supposed to do.

Am 25.12.2016 um 18:01 schrieb Christian Schulte:
> Am 12/25/16 um 11:57 schrieb Robert Scholte:
>> In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte   
>> wrote:
>>
>>> Am 12/24/16 um 18:40 schrieb Guillaume Boué:
 Why would the PMD plugin care about what Doxia require transitively?
 Christian, can you explain a bit more why those changes are needed?
>>>
>>> Classpath consistency. Running the unit tests with a completely
>>> different classpath than what the plugin is using at runtime makes those
>>> unit tests meaningless, so to say.
>>>
>>
>> We're talking about *unittests*, they should test one unit. In those cases  
>> there should be no issue which such dependencies, because if that unit  
>> requires a certain dependency, it should already have been defined as  
>> direct dependency.
> 
> Exactly. In the "widest" scope required. In this case, that's not the
> test scope but the compile scope. It's not the test scope overriding the
> compile scope here. It's the nearest declaration overriding a transitive
> dependency in an incompatible way. What if those two dependencies
> (compile and test) would require different major versions of that
> dependency? That's the "one tree per project" issue I have been talking
> about.
> 
>> If a test framework requires a newer version of some dependency also  
>> required at compile time, it is weird to be forced to upgrade this  
>> dependency just for testing (and what if this dependency is compiled with  
>> a newer version of Java compared to the max of the project).
> 
> Still means you are not testing the runtime classpath. You know things
> are working in test scope. There are different artifacts in the runtime
> scope you never have tested. The ITs are different. You would need to
> duplicate all unit tests in the ITs. That's not possible most of the
> time (you are executing goals in the ITs - you cannot instantiate a
> class and perform various tests with that from the ITs).
> 
>> Maybe it is also caused by the current implementation of test tools. JUnit  
>> is using its own classpath for everything. I've been talking with them if  
>> it would make sense to give the JUnit engine, the test classes and the  
>> main classes all their own classloader. That would make it possible to  
>> have better separation.
>>
>> I understand the statement of classpath consistency, I used to think like  
>> that in the past too, but for *unit*testing this shouldn't matter. That's  
>> why integration tests are just as important.
> 
> All I did is make an implementation behave as is documented in it's
> Javadoc. Please take a look at this class.
> 
> 
> 
> Read the Javadoc of all constructors. Concentrate on direct vs.
> transitive here. Read the Javadoc of the getDependencies and
> addDependency methods as well. Again, concentrate on direct vs.
> transitive here as well.
> 
> Now read the Javadoc of this class.
> 
> 
> 
> /**
>  * A dependency selector that filters transitive dependencies based on
> their scope. Direct dependencies are always
>  * included regardless of their scope. Note: This filter does
> not assume any relationships between the scopes.
>  * In particular, the filter is not aware of scopes that logically
> include other scopes.
>  *
>  * @see Dependency#getScope()
>  */
> public final class ScopeDependencySelector
> implements DependencySelector
> 
> The class calling into this is the DefaultDependencyCollector.
> 
> 
> 
> Do you notice there is an inconsistency in that 'CollectRequest' class
> depending on the way it gets constructed? The 'getDependencies' method
> clearly states:
> 
> @return The direct dependencies, never {@code null}.
> 
> Now compare if that statement is correct (direct vs. transitive)
> depending on how that class has 

Re: [VOTE] Releasing Wagon 2.11

[Dan Tran]

Thank Michael

  * Test failures at windows are intermittent.  It is a known issue since
the last few versions
  * No issue at my local redhat 7/java7 build
  * I am seeing test failures at
https://builds.apache.org/view/All/job/maven-wagon/1323/starting with
your change for WAGON-472. Dont think it is related, could be from build env


Thanks

On Sat, Dec 24, 2016 at 5:07 AM, Michael Osipov  wrote:

> Am 2016-12-24 um 04:07 schrieb Dan Tran:
>
>> Hi,
>>
>> We have fixed 18 issues:
>> *https://issues.apache.org/jira/secure/ReleaseNote.jspa?proj
>> ectId=12318122=1296
>> > ectId=12318122=1296>*
>>
>> There are still issues left in JIRA:
>> *https://issues.apache.org/jira/issues/?jql=project%20%3D%
>> 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>> 20created%20DESC%2C%20priority%20DESC
>> > 20WAGON%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
>> 20created%20DESC%2C%20priority%20DESC>*
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/maven-1313
>> https://repository.apache.org/content/repositories/maven-
>> 1313/org/apache/maven/wagon/wagon/2.11/wagon-2.11-source-release.zip
>>
>> Source release checksum(s):
>> wagon-2.11-source-release.zip sha1: 98bc0b031880b175e144c55447a620
>> 00c58abfa5
>>
>> Staging site:
>> *http://maven.apache.org/components/wagon-archives/wagon-LATEST/
>> *
>>
>> Guide to testing staged releases:
>> https://maven.apache.org/guides/development/guide-testing-releases.html
>> 
>> Vote open for 72H + 48H to accomodate for holidays
>>
>
> +1
>
> SHA1 is fine, site is fine. Builds passes on Windows but constantly fails
> on non-Windows, here on my FreeBSD machine as well as on our Jenkins Ubuntu
> slave. It should probably investigated for the 3.0 release.
>
> Michael
>
>
>
>
> -
> 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

[Christian Schulte]

Am 12/25/16 um 11:57 schrieb Robert Scholte:
> In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte   
> wrote:
> 
>> Am 12/24/16 um 18:40 schrieb Guillaume Boué:
>>> Why would the PMD plugin care about what Doxia require transitively?
>>> Christian, can you explain a bit more why those changes are needed?
>>
>> Classpath consistency. Running the unit tests with a completely
>> different classpath than what the plugin is using at runtime makes those
>> unit tests meaningless, so to say.
>>
> 
> We're talking about *unittests*, they should test one unit. In those cases  
> there should be no issue which such dependencies, because if that unit  
> requires a certain dependency, it should already have been defined as  
> direct dependency.

Exactly. In the "widest" scope required. In this case, that's not the
test scope but the compile scope. It's not the test scope overriding the
compile scope here. It's the nearest declaration overriding a transitive
dependency in an incompatible way. What if those two dependencies
(compile and test) would require different major versions of that
dependency? That's the "one tree per project" issue I have been talking
about.

> If a test framework requires a newer version of some dependency also  
> required at compile time, it is weird to be forced to upgrade this  
> dependency just for testing (and what if this dependency is compiled with  
> a newer version of Java compared to the max of the project).

Still means you are not testing the runtime classpath. You know things
are working in test scope. There are different artifacts in the runtime
scope you never have tested. The ITs are different. You would need to
duplicate all unit tests in the ITs. That's not possible most of the
time (you are executing goals in the ITs - you cannot instantiate a
class and perform various tests with that from the ITs).

> Maybe it is also caused by the current implementation of test tools. JUnit  
> is using its own classpath for everything. I've been talking with them if  
> it would make sense to give the JUnit engine, the test classes and the  
> main classes all their own classloader. That would make it possible to  
> have better separation.
> 
> I understand the statement of classpath consistency, I used to think like  
> that in the past too, but for *unit*testing this shouldn't matter. That's  
> why integration tests are just as important.

All I did is make an implementation behave as is documented in it's
Javadoc. Please take a look at this class.



Read the Javadoc of all constructors. Concentrate on direct vs.
transitive here. Read the Javadoc of the getDependencies and
addDependency methods as well. Again, concentrate on direct vs.
transitive here as well.

Now read the Javadoc of this class.



/**
 * A dependency selector that filters transitive dependencies based on
their scope. Direct dependencies are always
 * included regardless of their scope. Note: This filter does
not assume any relationships between the scopes.
 * In particular, the filter is not aware of scopes that logically
include other scopes.
 *
 * @see Dependency#getScope()
 */
public final class ScopeDependencySelector
implements DependencySelector

The class calling into this is the DefaultDependencyCollector.



Do you notice there is an inconsistency in that 'CollectRequest' class
depending on the way it gets constructed? The 'getDependencies' method
clearly states:

@return The direct dependencies, never {@code null}.

Now compare if that statement is correct (direct vs. transitive)
depending on how that class has been constructed and tell me why only
the ScopeDependencySelector above has had logic deciding if those
dependencies are transitive or direct when all other
selector,traverser,manager implementations did not.

There is this resolver only a few people seem to have taken a closer
look at. I am not telling anyone how things should behave and what has
to change etc. There is an API Maven is calling into no-one has ever
verified is doing what it is stating in it's Javadoc. Now compare the
Javadoc of those constructors of that CollectRequest class above to the
Javadoc of the getDependencies and addDependency methods of that same
class. Only one class (ScopeDependencySelector) handled things
differently (direct vs. transitive). There are 

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

[Hervé BOUTEMY]

good representation of such dependencies question we should work on, since I'm 
sure our current algorithm sometimes give wrong result from human point of 
view

What I don't know yet is if "human point of view" can be a simple algorithm 
improvement, or if there are some cases where there is no single good answer

Regards,

Hervé

Le dimanche 25 décembre 2016, 08:33:28 CET Stephen Connolly a écrit :
> How does a nearer transitive dependency get affected?
> 
> A->B(compile)->C->D
> A->E(test)->D
> 
> Will D now get Test scope or does it still retain compile
> 
> On Sun 25 Dec 2016 at 04:41, Christian Schulte  wrote:
> > Am 12/24/16 um 17:59 schrieb Hervé BOUTEMY:
> > > +1
> > > 
> > > 
> > > 
> > > notice that it may show that we have an issue with the way transitivity
> > > +
> > > 
> > > nearest resolution are applied
> > > 
> > > 
> > > 
> > > IIUC this case, we have:
> > > 
> > > 1. a direct dependency with scope = test
> > > 
> > > 2. a transitive dependency with scope = compile
> > > 
> > > 
> > > 
> > > the result can't be just the direct dependency with scope=test: scope of
> > > 
> > > direct dependency has to switch to compile (and I don't know which
> > 
> > version
> > 
> > > should be kept: direct or transitive)
> > 
> > Following the nearest node wins strategy, current master does exactly
> > 
> > what is expected. Adding a test scope dependency to a POM that is
> > 
> > already part of the test classpath just means that someone just did not
> > 
> > notice the dependency already is available to that scope due to other
> > 
> > reasons and that a scope is being overridden that way (by pulling it
> > 
> > nearer and overriding the scope).
> > 
> > 
> > 
> > Regards,
> > 
> > --
> > 
> > Christian
> > 
> > 
> > 
> > 
> > 
> > -
> > 
> > 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: svn commit: r1775971 - /maven/plugins/trunk/maven-pmd-plugin/pom.xml

[Hervé BOUTEMY]

I'm amused how your single question give 3 answers (I'll add mine) that are 
all accurate, but answer to a different interpretation of your question

my own interpretation of your question:
PMD plugin has some reporting goals, that depend on Doxia.
And if report mojos get Doxia dependencies injected by maven-site-plugin when 
run as reports, they can also be run as direct mojos, where maven-site-plugin 
is not there to inject any depency (be it declared or not, or declared but 
ignored)

My answer is as right as others, it's simply another interpretation of your 
question: every interpretation of your question looks reasonable, AFAIK nobody 
answered completely out of scope. Please tell us what more precise question 
was yours, and if you found your answer from the 3 :)

Regards

Hervé

Le samedi 24 décembre 2016, 18:40:22 CET Guillaume Boué a écrit :
> Why would the PMD plugin care about what Doxia require transitively?
> Christian, can you explain a bit more why those changes are needed?
> 
> Le 24/12/2016 à 17:59, Hervé BOUTEMY a écrit :
> > +1
> > 
> > notice that it may show that we have an issue with the way transitivity +
> > nearest resolution are applied
> > 
> > IIUC this case, we have:
> > 1. a direct dependency with scope = test
> > 2. a transitive dependency with scope = compile
> > 
> > the result can't be just the direct dependency with scope=test: scope of
> > direct dependency has to switch to compile (and I don't know which version
> > should be kept: direct or transitive)
> > 
> > I'm sure we have edge cases with transitive dependencies algorithm and
> > scopes
> > 
> > For a long time now, I want to create a builder API to create dependencies
> > unit tests, to ease creating tests, avoiding the nightmare of creating a
> > bunch of pom.xml files in a test local repo that are used by a unit test,
> > with hard to document rationale
> > Seems like it is time to work on it now...
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le samedi 24 décembre 2016, 17:03:03 CET Robert Scholte a écrit :
> >> With this commit commons-io gets the default scope.
> >> Suppose PMD drops commons-io, then there's no reason that this dependency
> >> has the compile scope.
> >> Assuming the unittests are using commons-io it makes sense that it has
> >> the
> >> test-scope.
> >> Be aware that users can overwrite dependencies of plugins in their
> >> pom.xml
> >> Developers can only know about the dependencies for their src/main/java
> >> and src/test/java code, and cannot do any assumptions about transitive
> >> dependencies due to all the override mechanisms in Maven.
> >> It may be clear that I don't like these changes.
> >> 
> >> Robert
> >> 
> >> On Sat, 24 Dec 2016 15:56:53 +0100,  wrote:
> >>> Author: schulte
> >>> Date: Sat Dec 24 14:56:53 2016
> >>> New Revision: 1775971
> >>> 
> >>> URL: http://svn.apache.org/viewvc?rev=1775971=rev
> >>> Log:
> >>> [MPMD-230] Required class missing: org/apache/commons/io/IOUtils
> >>> 
> >>> Modified:
> >>>  maven/plugins/trunk/maven-pmd-plugin/pom.xml
> >>> 
> >>> Modified: maven/plugins/trunk/maven-pmd-plugin/pom.xml
> >>> URL:
> >>> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/pom.xm
> >>> l?
> >>> rev=1775971=1775970=1775971=diff
> >>> 
> >>> =
> >>> = --- maven/plugins/trunk/maven-pmd-plugin/pom.xml (original)
> >>> +++ maven/plugins/trunk/maven-pmd-plugin/pom.xml Sat Dec 24 14:56:53
> >>> 2016
> >>> @@ -216,13 +216,13 @@ under the License.
> >>> 
> >>> org.apache.httpcomponents
> >>> httpclient
> >>> 4.3.5
> >>> 
> >>> -  test
> >>> +  
> >>> 
> >>>   
> >>>   
> >>>   
> >>> commons-io
> >>> commons-io
> >>> 2.5
> >>> 
> >>> -  test
> >>> +  
> >>> 
> >>>   
> >>> 
> >>> 
> >> 
> >> -
> >> 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
> 
> ---
> 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



-
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

[Robert Scholte]

I think we should finetune the definition of "nearest wins"-strategy:  
Which elements are matchers and which are merged? What happens to the  
scope? Is it different for direct and transitive dependencies?


On Sun, 25 Dec 2016 05:21:00 +0100, Christian Schulte   
wrote:



Am 12/24/16 um 17:03 schrieb Robert Scholte:

With this commit commons-io gets the default scope.
Suppose PMD drops commons-io, then there's no reason that this  
dependency

has the compile scope.
Assuming the unittests are using commons-io it makes sense that it has  
the

test-scope.


Putting that dependency into that POM makes it the nearest declaration
during resolving dependencies. When using test scope, that will
disappear from the plugin's runtime (application) classpath and that
will make the plugin blow up. It's a test dependency of the plugin and
also a transitive compile dependency of some compile dependency of the
plugin.

Be aware that users can overwrite dependencies of plugins in their  
pom.xml

Developers can only know about the dependencies for their src/main/java
and src/test/java code, and cannot do any assumptions about transitive
dependencies due to all the override mechanisms in Maven.


If the ITs would have failed right from the start, the person adding
those test dependencies would have done the right thing back then.


It may be clear that I don't like these changes.


I haven't expected anything else :-) What has led to that bugfix in the
resolver was something completely different. I hadn't expected such an
impact back then. From what I can tell so far, it's really uncovering
bugs in the POMs. The "one tree per project" logic is what makes this
look strange. Someone adds a test dependency to a project to express
that dependency to be needed during testing although that same
dependency also is needed in the application/main classpath. Looks like
this will be handled way more intelligent in model version 5.0.0, from
what I can tell. Right now we have that "nearest wins" strategy in model
version 4.0.0. If the nearest node happens to be in test scope, that
nearest node will not be part of the main/application/project/you name
it classpath. I would want the test classpath used to run all unit tests
to match what is used at runtime. For this, plugins need to be resolved
the same way as projects. Taking a closer look at this, Hervé raised
another very valid point. The resolver still throws away non-transitive
nodes the next level in the hierarchy during collecting dependencies.
Following that "there should never be a difference between project or
dependency resolution" statement of Hervé, the resolver should really
never cut off any nodes during collecting dependencies and should pass
all of what is there to the conflict resolver. Implementing that looks
easy (one line of code to change). I doubt the conflict resolver will
handle that new "input tree" correctly immediately. Will give it a try
locally, though.

Regards,


-
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

[Robert Scholte]

In Sun, 25 Dec 2016 05:23:14 +0100, Christian Schulte   
wrote:



Am 12/24/16 um 18:40 schrieb Guillaume Boué:

Why would the PMD plugin care about what Doxia require transitively?
Christian, can you explain a bit more why those changes are needed?


Classpath consistency. Running the unit tests with a completely
different classpath than what the plugin is using at runtime makes those
unit tests meaningless, so to say.



We're talking about *unittests*, they should test one unit. In those cases  
there should be no issue which such dependencies, because if that unit  
requires a certain dependency, it should already have been defined as  
direct dependency.
If a test framework requires a newer version of some dependency also  
required at compile time, it is weird to be forced to upgrade this  
dependency just for testing (and what if this dependency is compiled with  
a newer version of Java compared to the max of the project).
Maybe it is also caused by the current implementation of test tools. JUnit  
is using its own classpath for everything. I've been talking with them if  
it would make sense to give the JUnit engine, the test classes and the  
main classes all their own classloader. That would make it possible to  
have better separation.


I understand the statement of classpath consistency, I used to think like  
that in the past too, but for *unit*testing this shouldn't matter. That's  
why integration tests are just as important.


Robert



-
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

[Stephen Connolly]

How does a nearer transitive dependency get affected?

A->B(compile)->C->D
A->E(test)->D

Will D now get Test scope or does it still retain compile
On Sun 25 Dec 2016 at 04:41, Christian Schulte  wrote:

> Am 12/24/16 um 17:59 schrieb Hervé BOUTEMY:
>
> > +1
>
> >
>
> > notice that it may show that we have an issue with the way transitivity +
>
> > nearest resolution are applied
>
> >
>
> > IIUC this case, we have:
>
> > 1. a direct dependency with scope = test
>
> > 2. a transitive dependency with scope = compile
>
> >
>
> > the result can't be just the direct dependency with scope=test: scope of
>
> > direct dependency has to switch to compile (and I don't know which
> version
>
> > should be kept: direct or transitive)
>
>
>
> Following the nearest node wins strategy, current master does exactly
>
> what is expected. Adding a test scope dependency to a POM that is
>
> already part of the test classpath just means that someone just did not
>
> notice the dependency already is available to that scope due to other
>
> reasons and that a scope is being overridden that way (by pulling it
>
> nearer and overriding the scope).
>
>
>
> Regards,
>
> --
>
> Christian
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> --
Sent from my phone