[jira] [Comment Edited] (SUREFIRE-1650) Running multiple xml using suiteXmlFiles resulting in 0 test count

2019-10-22 Thread Mark Han (Jira) 


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957510#comment-16957510
 ] 

Mark Han edited comment on SUREFIRE-1650 at 10/23/19 3:03 AM:
--

Wow, has this been reproduced? I think I have been experiencing this too. Will 
try to repro with a small sample asap.


was (Author: markhan):
Wow, has this been reproduced? I think I have been experiencing this too.

> Running multiple xml using suiteXmlFiles resulting in 0 test count
> --
>
> Key: SUREFIRE-1650
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1650
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 3.0.0-M3
>Reporter: Gavrila Budiwijaya
>Priority: Major
> Attachments: Zero Test Count.png
>
>
> POM setup:
> {code:java}
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M3
> 
> 
> 
> -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
>  -Dcucumber.options="--plugin 
> io.qameta.allure.cucumber4jvm.AllureCucumber4Jvm"
> 
> 
> ${suiteXmlFile}
> 
> 
> ${config}
> 
> 
> 
> {code}
> Run using command line and multiple xml will results in 0 test count
> {code:java}
> mvn clean test -Dconfig="D:\configs\api\Automation - API - Staging.cfg" 
> -DsuiteXmlFile="xml/regression/fintech/TestMain.xml","xml/regression/loyalty/TestMain.xml","xml/regression/payment/TestMain.xml"
> {code}
> The results will display correct counter when I run single xml file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1650) Running multiple xml using suiteXmlFiles resulting in 0 test count

2019-10-22 Thread Mark Han (Jira) 


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957510#comment-16957510
 ] 

Mark Han commented on SUREFIRE-1650:


Wow, has this been reproduced? I think I have been experiencing this too.

> Running multiple xml using suiteXmlFiles resulting in 0 test count
> --
>
> Key: SUREFIRE-1650
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1650
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 3.0.0-M3
>Reporter: Gavrila Budiwijaya
>Priority: Major
> Attachments: Zero Test Count.png
>
>
> POM setup:
> {code:java}
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.0.0-M3
> 
> 
> 
> -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
>  -Dcucumber.options="--plugin 
> io.qameta.allure.cucumber4jvm.AllureCucumber4Jvm"
> 
> 
> ${suiteXmlFile}
> 
> 
> ${config}
> 
> 
> 
> {code}
> Run using command line and multiple xml will results in 0 test count
> {code:java}
> mvn clean test -Dconfig="D:\configs\api\Automation - API - Staging.cfg" 
> -DsuiteXmlFile="xml/regression/fintech/TestMain.xml","xml/regression/loyalty/TestMain.xml","xml/regression/payment/TestMain.xml"
> {code}
> The results will display correct counter when I run single xml file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] dejan2609 commented on issue #233: [SUREFIRE-1494] default provider for JUnit4 integration tests is changed (from 'surefire-junit4' to 'surefire-junit47')

2019-10-22 Thread GitBox 
dejan2609 commented on issue #233: [SUREFIRE-1494] default provider for JUnit4 
integration tests is changed (from 'surefire-junit4' to 'surefire-junit47')
URL: https://github.com/apache/maven-surefire/pull/233#issuecomment-545220293
 
 
   Gotcha @Tibor17 


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-22 Thread Stephane Landelle (Jira) 


[ 
https://issues.apache.org/jira/browse/WAGON-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957369#comment-16957369
 ] 

Stephane Landelle commented on WAGON-568:
-

I won't be able to investigate until next Friday, sorry.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: WAGON-568
> URL: https://issues.apache.org/jira/browse/WAGON-568
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.3.3
> Environment: 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 
> PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
> openjdk version "1.8.0_202"
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_202-b08)
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.202-b08, mixed mode)
>Reporter: Stephane Landelle
>Priority: Major
>
> I've been trying to release AsyncHttpClient for days and deployment was 
> always super slow until it ultimately failed or completely stalled.
> The issue seems to be that maven-deploy-plugin wants to upload checksum 
> files. I have no idea where those would come from, as far as I know, those 
> are generated by the maven repository.
>  
> {code:java}
> [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ 
> async-http-client-project ---
> Uploading to sonatype-nexus-staging: 
> http://oss.sonatype.org/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom
> [WARNING] Failed to upload checksum 
> org/asynchttpclient/async-http-client-project/2.0.40/async-http-client-project-2.0.40.pom.sha1:
>  null{code}
>  
>  
> For each actual file, maven-deploy-plugin tries to upload a sha1 and a md5 
> files and this takes forever to ultimately fail.
> I tried upgrading plugins but nothing worked.
> I finally found [this 
> ticket|[https://issues.sonatype.org/browse/OSSRH-43371?focusedCommentId=610865&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-610865]]
>  against Sonatype OSS describing the exact same behavior and stating 
> downgrading to maven 3.5.3 fixed the issue.
> Indeed, downgrading did the trick!
> I'm opening an issue here and not against OSS Sonatype as it looks like a 
> maven regression to me.
>  * maven 3.6.2: fails
>  * maven 3.5.4: fails
>  * maven 3.5.3: works like a charm



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-10-22 Thread Robert Scholte (Jira) 


[ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957314#comment-16957314
 ] 

Robert Scholte commented on MNG-6759:
-

I see what you mean. Relocations aren't used that much, but let's cover that 
case as well. I would expect that with a {{legacy-dependency-in-custom-repo}} 
that has a relocation to {{dependency-in-custom-repo}} you should already have 
your testcase. I'd suggest to add a second testmethod to 
{{MavenITmng6759TransitiveDependencyRepositoriesTest}}, but it must install 2 
artifacts (just to have the wording correct: you cannot install/deploy 
dependencies, you can only install artifacts, see also 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html)


> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-wagon] michael-o commented on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
michael-o commented on issue #57: WAGON-567: support retry on server side errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545111098
 
 
   @ColinHebert  OK, I guess I need to discuss with other HttpComponents devs 
whether we should really split client and servers errors. `BackoffManager` for 
client errors and the `ServiceUnavailable...` stuff for the server side. If I 
won't get a reaction from others, I will go the route we have discussed here.
   
   @ok2c Can you drop a few words here? Thanks!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] ColinHebert edited a comment on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
ColinHebert edited a comment on issue #57: WAGON-567: support retry on server 
side errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545081565
 
 
   > Do you think that using the ServiceUnavailableRetryStrategy is really the 
wrong way to go?
   
   I think it's "good enough" to begin with. This is a strict upgrade to the 
current behaviour which is failing fast on requests that we know we should 
retry. Keeping complexity low could be either dropping backoff entirely (if 
we're retrying 3 times only by default, a backoff strategy feels unnecessarily 
complex to begin with) or delegating that entirely to the HTTPClient (but as I 
said I'm not well versed into HTTPClient's ability to backoff out of the box).
   
   > Both NPM and Gradle approaches seem to generic for me, saying all 5xy can 
be repeated does not make sense.
   
   I believe that the intent is more along the lines of "we do not expect a 5xx 
from a user-configured repository on a fairly simple GET request, therefore we 
might want to consider it a transient error". If you wish to limit it though, I 
would strongly suggest to add 500 to the list of handled errors as many HTTP 
Servers use it as a catchall (therefore it has a non zero probably of being 
simply retryable)


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] ColinHebert commented on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
ColinHebert commented on issue #57: WAGON-567: support retry on server side 
errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545081565
 
 
   > Do you think that using the ServiceUnavailableRetryStrategy is really the 
wrong way to go?
   
   I think it's "good enough" to begin with. This is a strict upgrade to the 
current behaviour which is failing fast on behaviour that we know we should 
retry. Keeping complexity low could be either dropping backoff entirely (if 
we're retrying 3 times only, a backoff strategy feels unnecessary) or 
delegating that entirely to the HTTPClient (but as I said I'm not well versed 
into HTTPClient's ability to backoff out of the box).
   
   > Both NPM and Gradle approaches seem to generic for me, saying all 5xy can 
be repeated does not make sense.
   
   I believe that the intent is more along the lines of "we do not expect a 5xx 
from a user-configured repository on a fairly simple GET request, therefore we 
might want to consider it a transient error". If you wish to limit it though, I 
would strongly suggest to add 500 to the list of handled errors as many HTTP 
Servers use it as a catchall (therefore it has a non zero probably of being 
simply retryable)


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (WAGON-566) Fix for MSITE-738

2019-10-22 Thread Michael Osipov (Jira) 


[ 
https://issues.apache.org/jira/browse/WAGON-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957240#comment-16957240
 ] 

Michael Osipov commented on WAGON-566:
--

[~olegk], I need your expertise here. I have read RFC 3986, section 6.2.2.3. As 
far as I understand that dot-segments may occur in an abslolute URI. What I 
don't understand from the spec: who has to resolve (normalize) the URI? Cllent 
prior sending or the server receiving it? So do we have to do this in Wagon?

> Fix for MSITE-738
> -
>
> Key: WAGON-566
> URL: https://issues.apache.org/jira/browse/WAGON-566
> Project: Maven Wagon
>  Issue Type: Improvement
>  Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Steve Brown
>Priority: Major
>  Labels: easyfix, newbie
> Fix For: 3.3.4
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> This is a simple fix for MSITE-738. I have set the priority as Major because 
> that is the priority set for MSITE-738
> Some Repository Managers, e.g. JFrog's Artifactory, do not allow puts to a 
> URL with relative path elements ("." or "..").
> Artifactory are addressing the issue for downloads from remote sites 
> ([RTFACT-16457|https://www.jfrog.com/jira/browse/RTFACT-16457]).  Artifactory 
> returns this error:
> {{"status" : 500,"}}
>  {{"Path element cannot end with a dot: sites/ ... redacted ... */../*"}}
> The fix is to amend 
>  {{org.apache.maven.wagon.shared.http.EncodeUtils.encodeURL( String url )}}
>   to normalize the returned URI.
> I will create a pull request.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-wagon] michael-o commented on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
michael-o commented on issue #57: WAGON-567: support retry on server side errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545076457
 
 
   I will inquire why 429 is not included in the default config.
   
   * Alright, shall do so
   * I haven't even considered both Backoff interfaces. I don't even know 
whether a backoff is suited for 503 or rather 429, I guess for 429 only 
(throttling). I'd like to keep complexity low here and don't open new 
wormholes. Do you think that using the `ServiceUnavailableRetryStrategy` is 
really the wrong way to go?
   * Both NPM and Gradle approaches seem to generic for me, saying all 5xy can 
be repeated does not make sense. I would logically limit it to 503, 504 and at 
most 502. Everything else won't be solved by a retry.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] ColinHebert edited a comment on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
ColinHebert edited a comment on issue #57: WAGON-567: support retry on server 
side errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545071044
 
 
   Makes sense for `DefaultServiceUnavailableRetryStrategy`, I'm actually 
surprised 429 was not handled out of the box.
   
   Regarding the proposal:
- Makes sense for the default retry to be more reasonable. In CI/CD context 
the retry might need to be higher but for local development it's perfectly 
acceptable
- I am not sure you are going to be able to raise that timeout directly. 
The entire retry mechanism is encapsulated AFAIK into the HTTP client. What 
should really be happening there is having a backoff mechanism in the HTTP 
Client itself, there are BackoffManager as well as ConnectionBackoffStrategy 
that can be set, but I'm not familiar with their behaviour (I only know that 
they're not set by default)
- Makes sense again, it would be interesting to compare to prior art in 
that domain. I believe that @zymzxq started with something similar to npm 
https://github.com/npm/make-fetch-happen/blob/latest/index.js#L386-L392. 
Another interesting one is how gradle handles it: 
https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/repositories/transport/NetworkingIssueVerifier.java#L51
 there seems to be a general (well from the few examples I've seen so far) 
approach of 5xx being considered retryable as there are server side issues, and 
a strong consensus on 429 being a must retry.
- Ultimately this naming will have very little impact on the end user, so 
I'm indifferent to the naming here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] ColinHebert edited a comment on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
ColinHebert edited a comment on issue #57: WAGON-567: support retry on server 
side errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545071044
 
 
   Makes sense for `DefaultServiceUnavailableRetryStrategy`, I'm actually 
surprised 429 was not handled out of the box.
   
   Regarding the proposal:
- Makes sense for the default retry to be more reasonable. In CI/CD context 
the retry might need to be higher but for local development it's perfectly 
acceptable
- I am not sure you are going to be able to raise that time. The entire 
retry mechanism is encapsulated AFAIK into the HTTP client. What should really 
be happening there is having a backoff mechanism in the HTTP Client itself, 
there are BackoffManager as well as ConnectionBackoffStrategy that can be set, 
but I'm not familiar with their behaviour (I only know that they're not set by 
default)
- Makes sense again, it would be interesting to compare to prior art in 
that domain. I believe that @zymzxq started with something similar to npm 
https://github.com/npm/make-fetch-happen/blob/latest/index.js#L386-L392. 
Another interesting one is how gradle handles it: 
https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/repositories/transport/NetworkingIssueVerifier.java#L51
 there seems to be a general (well from the few examples I've seen so far) 
approach of 5xx being considered retryable as there are server side issues, and 
a strong consensus on 429 being a must retry.
- Ultimately this naming will have very little impact on the end user, so 
I'm indifferent to the naming here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] ColinHebert commented on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
ColinHebert commented on issue #57: WAGON-567: support retry on server side 
errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545071044
 
 
   Makes sense for `DefaultServiceUnavailableRetryStrategy`, I'm actually 
surprised 429 was not handled out of the box.
   
   Regarding the proposal:
- Makes sense for the default retry to be more reasonable. In CI/CD context 
the retry might need to be higher but for local development it's perfectly 
acceptable
- I am not sure you are going to be able to raise that time. The entire 
retry mechanism is encapsulated AFAIK into the HTTP client. What should really 
be happening there is having a backoff mechanism in the HTTP Client itself, 
there are BackoffManager as well as ConnectionBackoffStrategy that can be set, 
but I'm not familiar with their behaviour (I only know that they're not set by 
default)
- Makes sense again, it would be interesting to compare to prior art in 
that domain. I believe that @zymzxq started with something similar to npm 
https://github.com/npm/make-fetch-happen/blob/latest/index.js#L386-L392. 
Another interesting one is how gradle handles it: 
https://github.com/gradle/gradle/blob/master/subprojects/dependency-management/src/main/java/org/gradle/api/internal/artifacts/repositories/transport/NetworkingIssueVerifier.java#L51
- Ultimately this naming will have very little impact on the end user, so 
I'm indifferent to the naming here.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] eveardown commented on issue #55: Wagon-566

2019-10-22 Thread GitBox 
eveardown commented on issue #55: Wagon-566
URL: https://github.com/apache/maven-wagon/pull/55#issuecomment-545057532
 
 
   I'll take a loOK.
   
   On Tue, 22 Oct 2019, 17:35 Michael Osipov,  wrote:
   
   > I am considering merging this finally, but the modified class will likely
   > change due to WAGON-569.
   >
   > —
   > You are receiving this because you authored the thread.
   > Reply to this email directly, view it on GitHub
   > 
,
   > or unsubscribe
   > 

   > .
   >
   
   -- 
   
   
   This email and any
   files transmitted with it are confidential and solely 
   for the use of the intended
   recipient. This message contains confidential
   
   information and is intended only for the individual named. If you are not 
   the
   intended recipient you are notified that disclosing, copying, 
   distributing or
   taking any action in reliance on the contents of this 
   information is strictly
   prohibited. Please notify the sender immediately by 
   e-mail if you have
   received this e-mail by mistake and delete this e-mail 
   from your system.
   
   
   
    
   
   
   
   
   
   Computer
   viruses can be transmitted via email. 
   The recipient should check this email and
   any attachments for the presence 
   of viruses. Although the company has taken reasonable
   precautions to ensure 
   no viruses are present in this email, the company cannot
   accept 
   responsibility for any loss or damage arising from the use of this email
   or 
   attachments.
   
   
   
    
   
   
   
   
   
   
   Any views or opinions
   presented in this email are 
   solely those of the author and do not necessarily
   represent those of the 
   Estafet. Employees of Estafet are expressly required not
   to make defamatory 
   statements and not to infringe or authorize any infringement
   of copyright 
   or any other legal right by email communications. Any such
   communication is 
   contrary to company policy. The company will not accept any
   liability in 
   respect of such communication, and the employee responsible will
   be 
   personally liable for any damages or other liability arising.
   
   
   
    
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] michael-o commented on issue #55: Wagon-566

2019-10-22 Thread GitBox 
michael-o commented on issue #55: Wagon-566
URL: https://github.com/apache/maven-wagon/pull/55#issuecomment-545048503
 
 
   I am considering merging this finally, but the modified class will likely 
change due to WAGON-569.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Moved] (WAGON-569) Inconsistent encoding behavior for repository urls with spaces

2019-10-22 Thread Michael Osipov (Jira) 


 [ 
https://issues.apache.org/jira/browse/WAGON-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov moved MDEPLOY-261 to WAGON-569:
--

  Component/s: (was: deploy:deploy)
   wagon-http
Fix Version/s: (was: waiting-for-feedback)
   waiting-for-feedback
  Key: WAGON-569  (was: MDEPLOY-261)
Affects Version/s: (was: 3.0.0-M1)
   3.3.3
  Project: Maven Wagon  (was: Maven Deploy Plugin)

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: WAGON-569
> URL: https://issues.apache.org/jira/browse/WAGON-569
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.3.3
> Environment: OS: Windows 10
> mvn -v 
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
> 2018-10-24T11:41:47-07:00)
> Maven home: C:\
> Java version: 12.0.1, vendor: Oracle Corporation, runtime: C:\
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> mvn deploy version:  3.0.0-M1
> other plugins through effective pom:
> 
> 
>   maven-antrun-plugin
>   1.3
> 
> 
>   maven-assembly-plugin
>   2.2-beta-5
> 
> 
>   maven-dependency-plugin
>   2.8
> 
> 
>   maven-release-plugin
>   2.5.3
> 
> 
>   maven-clean-plugin
>   3.0.0
> 
> 
>   maven-resources-plugin
>   3.0.2
> 
> 
>   maven-compiler-plugin
>   3.7.0
> 
> 
>   maven-jar-plugin
>   3.0.2
> 
> 
>   maven-install-plugin
>   2.5.2
> 
> 
>   maven-deploy-plugin
>   2.8.2
> 
>   
>Reporter: Aasim Malladi
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: debug-log-2019-10-16-2.txt, debug-log-2019-10-16.txt
>
>
> Hi - I have a maven project that deploys its artifacts to a remote 
> repository. I have configured the remote repository both in the repositories 
> and distributionRepositories as follows: 
> {code:java}
>    
>     
>   id1  
>   https://hostname/test/spacyurl%20Spacy/maven/v1   
>
> true
>       
>
>true
>     
>     
>    
>    
>     
>   id1  
>   https://hostname/test/spacyurl%20Spacy/maven/v1   
>
> true
>      
>
>true
>    
>     
> 
> {code}
> As you can see my URL has spaces in it.
> When I run 'mvn install', it correctly uses the encoded URL with spaces and 
> downloads the dependencies. However, when I try to deploy this package to the 
> remote repo, it fails with a 404 not found error. On further investigation, 
> it looks like the URL is being encoded twice before the PUT request is sent. 
> If I remove the encoding, ie., put the URL with spaces, the deployment works, 
> however, the install fails.
> Let me know if you need more information about this.
> Aasim
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (WAGON-491) Add ability to set certificate via byte[] and not only via file

2019-10-22 Thread Michael Osipov (Jira) 


 [ 
https://issues.apache.org/jira/browse/WAGON-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed WAGON-491.

Fix Version/s: (was: waiting-for-feedback)
   Resolution: Won't Fix

No feedback received.

> Add ability to set certificate via byte[] and not only via file
> ---
>
> Key: WAGON-491
> URL: https://issues.apache.org/jira/browse/WAGON-491
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-ssh
>Reporter: Laurent Granié
>Priority: Major
> Attachments: 20181206-wagon-ssh.patch
>
>
> I'm using wagon outside Maven.
> I would like to authenticate on sftp servers via a certificate.
> It's possible today via a file with a file path but not if I include the 
> certificate in the .jar.
> I would like to be able to set the certificate with a byte[].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (WAGON-286) Configurable SCM comment prefix

2019-10-22 Thread Michael Osipov (Jira) 


 [ 
https://issues.apache.org/jira/browse/WAGON-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed WAGON-286.

Fix Version/s: (was: waiting-for-feedback)
   Resolution: Incomplete

No feedback received.

> Configurable SCM comment prefix
> ---
>
> Key: WAGON-286
> URL: https://issues.apache.org/jira/browse/WAGON-286
> Project: Maven Wagon
>  Issue Type: Improvement
>  Components: wagon-scm
>Affects Versions: 1.0-beta-6
>Reporter: Andrey Ashikhmin
>Priority: Major
> Attachments: scm.comment.prefix-against-wagon-scm-1.0-beta-6 .patch
>
>
> Currently Wagon SCM check in all files with a comment starting with "Wagon: ".
> It's desired (and sometimes necessary with certain SCM provider settings) to 
> configure it.
> maven-release-plugin is configurable in this area.
> I'm attaching a patch.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (WAGON-542) New wagon-zip provider

2019-10-22 Thread Michael Osipov (Jira) 


 [ 
https://issues.apache.org/jira/browse/WAGON-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed WAGON-542.

Fix Version/s: (was: waiting-for-feedback)
   Resolution: Won't Fix

No feedback received.

> New wagon-zip provider
> --
>
> Key: WAGON-542
> URL: https://issues.apache.org/jira/browse/WAGON-542
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: New Wagons
>Affects Versions: 3.2.0
>Reporter: Laurent Granié
>Priority: Major
>  Labels: newbie, patch
> Attachments: wagon-zip.patch
>
>
> By duplicating wagon-file and using TrueZip, I created wagon-zip.
> I've still got problems with StreamWagon.getIfNewerToStream : unit tests are 
> not working.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-10-22 Thread Jira 


[ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957178#comment-16957178
 ] 

Stig Rohde Døssing edited comment on MNG-6759 at 10/22/19 3:47 PM:
---

[~rfscholte] Thanks for taking a look at this.

There's potentially a related bug as the fast path also doesn't set the 
relocatedArtifact variable 
https://github.com/apache/maven/blob/db3e44694c631554aa9f4079b40b1c6f1e1f2f0d/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L220,
 which is also part of the return value of that method. I'm not sure what the 
impact is, or how to test it. 

I assume it has something to do with the mechanism for telling people about a 
move to a new GAV https://maven.apache.org/guides/mini/guide-relocation.html


was (Author: srdo):
[~rfscholte] Thanks for taking a look at this.

There's potentially a related bug as the fast path also doesn't set the 
relocatedArtifact variable 
https://github.com/apache/maven/blob/db3e44694c631554aa9f4079b40b1c6f1e1f2f0d/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L220,
 which is also part of the return value of that method. I'm not sure what the 
impact is, or how to test it. 

> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases

2019-10-22 Thread Jira 


[ 
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16957178#comment-16957178
 ] 

Stig Rohde Døssing commented on MNG-6759:
-

[~rfscholte] Thanks for taking a look at this.

There's potentially a related bug as the fast path also doesn't set the 
relocatedArtifact variable 
https://github.com/apache/maven/blob/db3e44694c631554aa9f4079b40b1c6f1e1f2f0d/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L220,
 which is also part of the return value of that method. I'm not sure what the 
impact is, or how to test it. 

> [REGRESSION] Maven fails to use  section from dependency when 
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent 
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process 
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies 
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR]   Try downloading the file manually from the project website.
> [ERROR]
> [ERROR]   Then, install it using the command:
> [ERROR]   mvn install:install-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file
> [ERROR]
> [ERROR]   Alternatively, if you host your own repository you can deploy the 
> file there:
> [ERROR]   mvn deploy:deploy-file -DgroupId=io.confluent 
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar 
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR]   Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR]   io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR]   apache.snapshots (https://repository.apache.org/snapshots, 
> releases=false, snapshots=true),
> [ERROR]   central (https://repo.maven.apache.org/maven2, releases=true, 
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at 
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven 
> 3.6.2 doesn't like?
> * Copying the  section from ChildB into ChildA



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-integration-testing] srdo commented on issue #50: [MNG-6759] - Add test demonstrating the issue where the wrong reposit…

2019-10-22 Thread GitBox 
srdo commented on issue #50: [MNG-6759] - Add test demonstrating the issue 
where the wrong reposit…
URL: 
https://github.com/apache/maven-integration-testing/pull/50#issuecomment-545023598
 
 
   Thanks for letting me know about the suite. Addressed your comments.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Closed] (WAGON-565) Do not skip retry on SSLException by default

2019-10-22 Thread Michael Osipov (Jira) 


 [ 
https://issues.apache.org/jira/browse/WAGON-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed WAGON-565.

Fix Version/s: (was: waiting-for-feedback)
   Resolution: Not A Problem

This has been fixed in Java 11+ now. No more wrapping.

> Do not skip retry on SSLException by default
> 
>
> Key: WAGON-565
> URL: https://issues.apache.org/jira/browse/WAGON-565
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Martin Furmanski
>Priority: Minor
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> The SSL stack in Java will transform any transport error into an 
> SSLException, so it is very bad to skip retries for this entire class of 
> exceptions. Transport errors are probably the number one reason why retries 
> are needed, so it defeats the purpose for any secure deployments using HTTPS.
> {code:java}
> Caused by: javax.net.ssl.SSLProtocolException: Connection reset
> at sun.security.ssl.Alert.createSSLException (Alert.java:126)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:321)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:264)
> at sun.security.ssl.TransportContext.fatal (TransportContext.java:259)
> at sun.security.ssl.SSLSocketImpl.handleException (SSLSocketImpl.java:1314)
> at sun.security.ssl.SSLSocketImpl$AppInputStream.read (SSLSocketImpl.java:839)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.streamRead
>  (SessionInputBufferImpl.java:137)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.fillBuffer
>  (SessionInputBufferImpl.java:153)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.readLine
>  (SessionInputBufferImpl.java:280)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
>  (DefaultHttpResponseParser.java:138)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead
>  (DefaultHttpResponseParser.java:56)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractMessageParser.parse
>  (AbstractMessageParser.java:259)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.receiveResponseHeader
>  (DefaultBHttpClientConnection.java:163)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.receiveResponseHeader
>  (CPoolProxy.java:157)
> at 
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doReceiveResponse
>  (HttpRequestExecutor.java:273)
> at 
> org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute
>  (HttpRequestExecutor.java:125)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute
>  (MainClientExec.java:272)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute
>  (ProtocolExec.java:185)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute
>  (RetryExec.java:89)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute
>  (RedirectExec.java:110)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute
>  (InternalHttpClient.java:185)
> at 
> org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute
>  (CloseableHttpClient.java:83)
> at 
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.execute
>  (AbstractHttpClientWagon.java:958)
> at 
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
>  (AbstractHttpClientWagon.java:1117)
> at 
> org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData
>  (AbstractHttpClientWagon.java:1094)
> at org.apache.maven.wagon.StreamWagon.getInputStream (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)
> {code}
> I realise this is the default of the HTTP client, but changing that library 
> is just too wide of a change in a patch, but for the maven wagon it sounds 
> quite safe and should help many people which experience this in their 
> deployments. The alternative is that everyone using HTTPS has to track down 
> this issue and tweak their configs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] Col-E opened a new pull request #249: Surefire-1701: Fix @DisplayName breaking reruns

2019-10-22 Thread GitBox 
Col-E opened a new pull request #249: Surefire-1701: Fix @DisplayName breaking 
reruns
URL: https://github.com/apache/maven-surefire/pull/249
 
 
   As discussed in 
[Surefire-1584](https://github.com/apache/maven-surefire/pull/245#issuecomment-543702810)
 there was a bug where `@DisplayName` would break rerun logic. This PR resolves 
both this bug and addresses another potential issue _(No triggering sample 
found though)_ where the `adapter` was treated as if it were stateless, but it 
is stateful.
   
   The platform provider unit test has been updated with `@DisplayName` usages 
to verify the correctness of this solution.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] michael-o edited a comment on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
michael-o edited a comment on issue #57: WAGON-567: support retry on server 
side errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-544947921
 
 
   @ColinHebert I really much like your proposal. As soon as this goes in I 
will deprecate and mark the current backoff mechanism for removal in 4.0.0.
   
   I am considering to modify `DefaultServiceUnavailableRetryStrategy` by 
accepting a set of possible status codes. I will discuss this with other 
HttpComponents committers since I am one.
   
   I think that the current backoff mechanism will be unavailable as soon as a 
new handler pops in or it will fail and the mech would pop in.
   
   My proposal is:
   
   * Lower default retry to 3 because the low level retry handler uses 3 too
   * Raise from default 1000 ms to 2000 ms to 2500 ms not to bomb a server and 
have a closer value to `maven.wagon.httpconnectionManager.backoffSeconds`
   * Introduce a Maven-default ("default") which handles 503 and 429.
   * Rename the custom impl to "extended" because it covers way more status 
codes.
   
   WDYT?
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [maven-wagon] michael-o commented on issue #57: WAGON-567: support retry on server side errors

2019-10-22 Thread GitBox 
michael-o commented on issue #57: WAGON-567: support retry on server side errors
URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-544947921
 
 
   @ColinHebert I really much like your proposal. As soon as this goes in I 
will deprecate and mark the current backoff mechanism for removal in 4.0.0.
   
   I am considering to modify `DefaultServiceUnavailableRetryStrategy` by 
accepting a set of possible status codes. I will discuss this with other 
HttpComponents committers since I am one.
   
   I think that the current backoff mechanism will be unavailable as soon as a 
new handler pops in or it will fail and the mech would pop in.
   
   My proposal is:
   
   * Lower default retry to 3 because the low level retry handler uses 3 too
   * Raise from default 1000 ms to 2000 ms to 2500 ms not to bomb a server and 
have a closer value to `maven.wagon.httpconnectionManager.backoffSeconds`
   * Introduce a Maven-default ("default") which handles 503 and 429.
   * Rename the custom impl to "extended" because it covers way more status 
codes.
   
   WDY?
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (MNG-6791) document hard and soft requirements

2019-10-22 Thread Elliotte Rusty Harold (Jira) 
Elliotte Rusty Harold created MNG-6791:
--

 Summary: document hard and soft requirements
 Key: MNG-6791
 URL: https://issues.apache.org/jira/browse/MNG-6791
 Project: Maven
  Issue Type: Improvement
  Components: Documentation:  General
Affects Versions: 3.6.2, 3.6.3
Reporter: Elliotte Rusty Harold


The docs at 
https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification 
say:

1.0: "Soft" requirement on 1.0 (just a recommendation, if it matches all other 
ranges for the dependency)
[1.0]: "Hard" requirement on 1.0

However, I don't think anywhere do we actually explain what a soft or a "Hard" 
requirement is. If someone can clarify this for me, I'll update the docs 
accordingly.





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-surefire] quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5

2019-10-22 Thread GitBox 
quiram commented on issue #245: Surefire-1584: Add option to rerun failing 
tests for JUnit5 
URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-544898214
 
 
   > This is actually a **one character** fix 🤦‍♂
   > 
   > [JUnitPlatformProvider - Line 
195](https://github.com/apache/maven-surefire/blob/d0230dcc93e6cd1b8171407237489fdf291cca48/surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java#L195)
   > 
   > When writing `buildLauncherDiscoveryRequestForRerunFailures` I called 
`String[] toClassMethodNameWithoutPlan()` to fetch the method name `source[3]`, 
but should be using `source[2]` instead.
   > 
   > * `source[3]` is the resolved method name _(Which uses `@DisplayName`'s 
value)_
   > * `source[2]` is the actual method name.
   > 
   > Changing `3` to `2` is all that is necessary.
   
   I wish all fixes were as easy as this 😄. I'm glad we got to the bottom of it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Closed] (SUREFIRE-1702) [JDK 11 Alpine Linux] JAR content is not flushed completely down to drive "Error: Invalid or corrupt jarfile target/surefire/surefirebooter13749914711390838584.jar"

2019-10-22 Thread Tibor Digana (Jira) 


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1702.
--
  Assignee: Tibor Digana
Resolution: Fixed

https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=8a886f3a44e23fc2bdcebac3804064e228a88b2a

> [JDK 11 Alpine Linux] JAR content is not flushed completely down to drive 
> "Error: Invalid or corrupt jarfile 
> target/surefire/surefirebooter13749914711390838584.jar"
> 
>
> Key: SUREFIRE-1702
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1702
> Project: Maven Surefire
>  Issue Type: Improvement
>  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
> forking
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M4
>
>
> We found an [error with a corrupted JAR 
> file|http://ldytyk.blogspot.com/2019/03/maven-tests-fail-with-forked-vm.html] 
> published by our users. They used Docker image 
> {{adoptopenjdk/openjdk11:jdk-11.0.2.9-alpine}} and reproduced the error by 
> the project [on GitHub|https://github.com/mxxk/mvn-surefire-plugin-failure].
> The plugin failure only occures when:
> * using Surefire's mode of forking a new JVM (the default behavior); and
> * On Docker image based on Alpine Linux. It does not reproduce on an image 
> based on Ubuntu.
> I checked some errors regarding Surefire on Alpine images and I found that 
> the plugin crashed immediately.
> {noformat}
> /app # java -jar target/surefire/surefirebooter13749914711390838584.jar
> Error: Invalid or corrupt jarfile 
> target/surefire/surefirebooter13749914711390838584.jar
> {noformat}
> then I decided to extract the file
> {noformat}
> /app # unzip target/surefire/surefirebooter13749914711390838584.jar -d 
> extracted
> {noformat}
> the manifest file has incomplete content:
> {noformat}
> cat extracted/META-INF/MANIFEST.MF
> Manifest-Version: 1.0
> Class-Path: ../../../root/.m2/repository/org/apache/maven/surefire/suref
>  ire-booter/3.0.0-SNAPSHOT/surefire-booter-3.0.0-SNAPSHOT.jar ../../../r
>  oot/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-SNAPSHO
>  T/surefire-api-3.0.0-SNAPSHOT.jar ../../../root/.m2/repository/org/apac
>  he/maven/surefire/surefire-logger-api/3.0.0-SNAPSHOT/surefire-logger-ap
>  i-3.0.0-SNAPSHOT.jar ../test-classes/ ../classes/ ../../../root/.m2/rep
>  ository/org/junit/jupiter/junit-jupiter-
> {noformat}
> If you zip the same again {{/app # jar cvf MyJar.jar extracted/.}} and start 
> the new JAR file separately:
> {noformat}
> /app # java -jar MyJar.jar
> Picked up JAVA_TOOL_OPTIONS:
> no main manifest attribute, in MyJar.jar
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SUREFIRE-1702) [JDK 11 Alpine Linux] JAR content is not flushed completely down to drive "Error: Invalid or corrupt jarfile target/surefire/surefirebooter13749914711390838584.jar"

2019-10-22 Thread Tibor Digana (Jira) 
Tibor Digana created SUREFIRE-1702:
--

 Summary: [JDK 11 Alpine Linux] JAR content is not flushed 
completely down to drive "Error: Invalid or corrupt jarfile 
target/surefire/surefirebooter13749914711390838584.jar"
 Key: SUREFIRE-1702
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1702
 Project: Maven Surefire
  Issue Type: Improvement
  Components: Maven Failsafe Plugin, Maven Surefire Plugin, process 
forking
Reporter: Tibor Digana
 Fix For: 3.0.0-M4


We found an [error with a corrupted JAR 
file|http://ldytyk.blogspot.com/2019/03/maven-tests-fail-with-forked-vm.html] 
published by our users. They used Docker image 
{{adoptopenjdk/openjdk11:jdk-11.0.2.9-alpine}} and reproduced the error by the 
project [on GitHub|https://github.com/mxxk/mvn-surefire-plugin-failure].

The plugin failure only occures when:
* using Surefire's mode of forking a new JVM (the default behavior); and
* On Docker image based on Alpine Linux. It does not reproduce on an image 
based on Ubuntu.

I checked some errors regarding Surefire on Alpine images and I found that the 
plugin crashed immediately.

{noformat}
/app # java -jar target/surefire/surefirebooter13749914711390838584.jar
Error: Invalid or corrupt jarfile 
target/surefire/surefirebooter13749914711390838584.jar
{noformat}

then I decided to extract the file

{noformat}
/app # unzip target/surefire/surefirebooter13749914711390838584.jar -d extracted
{noformat}

the manifest file has incomplete content:

{noformat}
cat extracted/META-INF/MANIFEST.MF
Manifest-Version: 1.0
Class-Path: ../../../root/.m2/repository/org/apache/maven/surefire/suref
 ire-booter/3.0.0-SNAPSHOT/surefire-booter-3.0.0-SNAPSHOT.jar ../../../r
 oot/.m2/repository/org/apache/maven/surefire/surefire-api/3.0.0-SNAPSHO
 T/surefire-api-3.0.0-SNAPSHOT.jar ../../../root/.m2/repository/org/apac
 he/maven/surefire/surefire-logger-api/3.0.0-SNAPSHOT/surefire-logger-ap
 i-3.0.0-SNAPSHOT.jar ../test-classes/ ../classes/ ../../../root/.m2/rep
 ository/org/junit/jupiter/junit-jupiter-
{noformat}

If you zip the same again {{/app # jar cvf MyJar.jar extracted/.}} and start 
the new JAR file separately:

{noformat}
/app # java -jar MyJar.jar
Picked up JAVA_TOOL_OPTIONS:
no main manifest attribute, in MyJar.jar
{noformat}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)