[jira] [Updated] (WAGON-566) Add support for URI normalization

2019-11-11 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-566:
-
Fix Version/s: waiting-for-feedback

> Add support for URI normalization
> -
>
> 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: waiting-for-feedback
>
>   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)


[jira] [Closed] (SUREFIRE-1715) Platform support for 'maven-surefire-plugin' on PowerPC64LE

2019-11-11 Thread Michael Osipov (Jira)


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

Michael Osipov closed SUREFIRE-1715.

Resolution: Invalid

This is not a Surefire issue. Inquire with upstream project.

> Platform support for 'maven-surefire-plugin' on PowerPC64LE
> ---
>
> Key: SUREFIRE-1715
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1715
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
> Environment: PPC64LE
>Reporter: Sarvesh Tamba
>Priority: Blocker
> Attachments: maven-surefire-plugin_error.txt
>
>
> I am trying to build/install keycloak/keycloak on PPC64LE architecture with 
> Red Hat Enterprise Linux 7, using the commands mentioned here - 
> https://github.com/keycloak/keycloak/blob/master/docs/building.md
> I have updated the `mvn-golang-wrapper` with workaround as described in 
> "https://github.com/raydac/mvn-golang/issues/70;
> However I am seeing the following issues as below:-
> ```
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
> project integration-arquillian-tests-base: There are test failures.
> ```
> Also seeing the following error in the log (not sure if the two are related)
> ```
> /root/keycloak/keycloak/testsuite/integration-arquillian/tests/base/target/drone/1c947d57fce2f21ce0b43fe2ed7cd361/phantomjs-2.1.1-linux-x86_64/bin/phantomjs:
>  cannot execute binary file
> ```
> Attached is the detailed log output.



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


[jira] [Commented] (WAGON-567) Provide request retry strategy on transient client and server side errors

2019-11-08 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-567:
--

They aren't the best, but the retry handler uses similar names. We wanted to 
keep it consistent for the users.

> Provide request retry strategy on transient client and server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Updated] (MNG-6800) 在执行 writePlugin 时 发生 ClassCastException

2019-11-07 Thread Michael Osipov (Jira)


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

Michael Osipov updated MNG-6800:

Fix Version/s: waiting-for-feedback

> 在执行 writePlugin 时 发生 ClassCastException 
> 
>
> Key: MNG-6800
> URL: https://issues.apache.org/jira/browse/MNG-6800
> Project: Maven
>  Issue Type: Improvement
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: glmapper
>Priority: Blocker
> Fix For: waiting-for-feedback
>
>
> {code:java}
> //代码占位符
> java.lang.ClassCastException: org.codehaus.plexus.util.xml.Xpp3Dom cannot be 
> cast to org.codehaus.plexus.util.xml.Xpp3Domjava.lang.ClassCastException: 
> org.codehaus.plexus.util.xml.Xpp3Dom cannot be cast to 
> org.codehaus.plexus.util.xml.Xpp3Dom at 
> org.apache.maven.model.io.xpp3.MavenXpp3Writer.writePlugin(MavenXpp3Writer.java:1417)
>  at 
> org.apache.maven.model.io.xpp3.MavenXpp3Writer.writeBuild(MavenXpp3Writer.java:329)
>  at 
> org.apache.maven.model.io.xpp3.MavenXpp3Writer.writeModel(MavenXpp3Writer.java:1115)
>  at 
> org.apache.maven.model.io.xpp3.MavenXpp3Writer.write(MavenXpp3Writer.java:100)
> {code}



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


[jira] [Commented] (WAGON-567) Provide request retry strategy on transient client and server side errors

2019-11-07 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-567:
--

[~hboutemy], looking into your question: no default behavior change has been 
applied. If you don't specifiy 
{{maven.wagon.http.serviceUnavailableRetryStrategy.class != none}}, nothing 
will change.

I agree that the names are a bit irritating, but the refer to 
{{DefaultServiceUnavailableRetryStrategy}} and 
{{StandardServiceUnavailableRetryStrategy}} provided by the {{HttpClient}}, no 
custom implementations. This will be merged with the retry handler as soon as 
HTTPCLIENT-2019 is solved in 5.0 and we switch to 5.0.

> Provide request retry strategy on transient client and server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Commented] (WAGON-567) Provide request retry strategy on transient client and server side errors

2019-11-07 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-567:
--

[~hboutemy], I will go on detail on this later this day as soon as I have 
access to my dev machine. But right away, as {{none}} is the default impl no 
retried are retried. Though, we have a retry handler in place for transport 
errors. See also HTTPCLIENT-2019. I plan to rework this in HttpClient and have 
constent handling.

> Provide request retry strategy on transient client and server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Commented] (MJAR-267) Propertize addDefaultImplementationEntries and addDefaultSpecificationEntries

2019-11-05 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MJAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16967462#comment-16967462
 ] 

Michael Osipov commented on MJAR-267:
-

I do not understand its purpose because I do not understand the problem itself.

> Propertize addDefaultImplementationEntries and addDefaultSpecificationEntries
> -
>
> Key: MJAR-267
> URL: https://issues.apache.org/jira/browse/MJAR-267
> Project: Maven JAR Plugin
>  Issue Type: Sub-task
>Reporter: Peter Rader
>Priority: Minor
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The version-entries of MANIFEST.MF are important requirements to a couple of 
> frameworks (eclipse, felix, liferay) and specifications (portlets, osgi) in 
> order to load those modules in an consistent way.
> At the moment this deal-breaking configuration of the project is essential in 
> order to create an valid portlet / osgi-modul. Without having the 
> boolean-values as properties we encounter three downsides:
>  # Only using an indispensable dirty mid-size overhead of overriding the 
> MJAR's modul-configuration we can force MJAR to create this essential 
> MANIFEST.MF-entries.
>  # We are unable to early fail the build on missing 
> MANIFEST.MF-version-entries. Even more worse the build will generate invalid 
> osgi/portlets quitting "successfully".
>  # A CI server like Hudson or Jenkins is not able to flange the 
> MANIFEST.MF-version-entries hindsightly.
> Suggestion:
> Be able to direct the generation of version informations like this:
> {quote}{{mvn clean install -Dmaven.addDefaultImplementationEntries=true 
> -Dmaven.addDefaultSpecificationEntries=true}}
> {quote}



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


[jira] [Commented] (MNG-6798) build-helper-maven-plugin: java.lang.IllegalArgumentException: version can neither be null, empty nor blank

2019-11-04 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6798:
-

[~khmarbaise]

> build-helper-maven-plugin: java.lang.IllegalArgumentException: version can 
> neither be null, empty nor blank
> ---
>
> Key: MNG-6798
> URL: https://issues.apache.org/jira/browse/MNG-6798
> Project: Maven
>  Issue Type: Bug
>  Components: Plugins and Lifecycle
>Affects Versions: 3.6.2
>Reporter: Jamin Collins
>Priority: Major
>
> After upgrading to maven 3.6.2 I found that I could no longer successfully 
> build one of my projects.  The error:
> {quote}
>  [ERROR] Failed to execute goal 
> org.codehaus.mojo:build-helper-maven-plugin:3.0.0:released-version 
> (released-version) on project forge-gui-desktop: Execution released-version 
> of goal org.codehaus.mojo:build-helper-maven-plugin:3.0.0:released-version 
> failed: version can neither be null, empty nor blank -> [Help 1]
> {quote}
> seemed to indicate a problem with one of the plugins, specifically 
> *build-helper-maven-plugin*.  However, I have found that rolling maven (and 
> only maven) back to 3.6.1 allows the project to build.  So, this appears to 
> be a problem with maven and not the plugin.



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


[jira] [Commented] (MJAR-267) Propertize addDefaultImplementationEntries and addDefaultSpecificationEntries

2019-11-04 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MJAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16966593#comment-16966593
 ] 

Michael Osipov commented on MJAR-267:
-

Frankly, I absolutely do not understand the problem. You have both entry sets. 
Can you rephrase your problem?

> Propertize addDefaultImplementationEntries and addDefaultSpecificationEntries
> -
>
> Key: MJAR-267
> URL: https://issues.apache.org/jira/browse/MJAR-267
> Project: Maven JAR Plugin
>  Issue Type: Sub-task
>Reporter: Peter Rader
>Priority: Minor
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The version-entries of MANIFEST.MF are important requirements to a couple of 
> frameworks (eclipse, felix, liferay) and specifications (portlets, osgi) in 
> order to load those modules in an consistent way.
> At the moment this deal-breaking configuration of the project is essential in 
> order to create an valid portlet / osgi-modul. Without having the 
> boolean-values as properties we encounter three downsides:
>  # Only using an indispensable dirty mid-size overhead of overriding the 
> MJAR's modul-configuration we can force MJAR to create this essential 
> MANIFEST.MF-entries.
>  # We are unable to early fail the build on missing 
> MANIFEST.MF-version-entries. Even more worse the build will generate invalid 
> osgi/portlets quitting "successfully".
>  # A CI server like Hudson or Jenkins is not able to flange the 
> MANIFEST.MF-version-entries hindsightly.
> Suggestion:
> Be able to direct the generation of version informations like this:
> {quote}{{mvn clean install -Dmaven.addDefaultImplementationEntries=true 
> -Dmaven.addDefaultSpecificationEntries=true}}
> {quote}



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


[jira] [Issue Comment Deleted] (MJAR-267) Propertize addDefaultImplementationEntries and addDefaultSpecificationEntries

2019-11-04 Thread Michael Osipov (Jira)


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

Michael Osipov updated MJAR-267:

Comment: was deleted

(was: This will require an ASM upgrade.)

> Propertize addDefaultImplementationEntries and addDefaultSpecificationEntries
> -
>
> Key: MJAR-267
> URL: https://issues.apache.org/jira/browse/MJAR-267
> Project: Maven JAR Plugin
>  Issue Type: Sub-task
>Reporter: Peter Rader
>Priority: Minor
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The version-entries of MANIFEST.MF are important requirements to a couple of 
> frameworks (eclipse, felix, liferay) and specifications (portlets, osgi) in 
> order to load those modules in an consistent way.
> At the moment this deal-breaking configuration of the project is essential in 
> order to create an valid portlet / osgi-modul. Without having the 
> boolean-values as properties we encounter three downsides:
>  # Only using an indispensable dirty mid-size overhead of overriding the 
> MJAR's modul-configuration we can force MJAR to create this essential 
> MANIFEST.MF-entries.
>  # We are unable to early fail the build on missing 
> MANIFEST.MF-version-entries. Even more worse the build will generate invalid 
> osgi/portlets quitting "successfully".
>  # A CI server like Hudson or Jenkins is not able to flange the 
> MANIFEST.MF-version-entries hindsightly.
> Suggestion:
> Be able to direct the generation of version informations like this:
> {quote}{{mvn clean install -Dmaven.addDefaultImplementationEntries=true 
> -Dmaven.addDefaultSpecificationEntries=true}}
> {quote}



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


[jira] [Commented] (MDEP-663) Analyze failed: Unsupported class file major version 57 (Java 13)

2019-11-04 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEP-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16966590#comment-16966590
 ] 

Michael Osipov commented on MDEP-663:
-

This will require an ASM upgrade.

> Analyze failed: Unsupported class file major version 57 (Java 13)
> -
>
> Key: MDEP-663
> URL: https://issues.apache.org/jira/browse/MDEP-663
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Reporter: Sudhesh RAJAN SHARMA
>Priority: Major
> Attachments: StackTrace.txt
>
>
> Class file of major version 57 (Java 13) is not yet supported by Maven 
> Dependency Plugin.
> {{While executing goal 
> org.apache.maven.plugins:maven-dependency-plugin:3.1.1:analyze-only}} on 
> classes created by Java 13 build failed. Refer to the attached log 
> ([^StackTrace.txt]).
>  
> Java: OpenJDK 13 
> asm version: 7.2



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


[jira] [Commented] (MJAR-267) Propertize addDefaultImplementationEntries and addDefaultSpecificationEntries

2019-11-04 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MJAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16966558#comment-16966558
 ] 

Michael Osipov commented on MJAR-267:
-

This will require an ASM upgrade.

> Propertize addDefaultImplementationEntries and addDefaultSpecificationEntries
> -
>
> Key: MJAR-267
> URL: https://issues.apache.org/jira/browse/MJAR-267
> Project: Maven JAR Plugin
>  Issue Type: Sub-task
>Reporter: Peter Rader
>Priority: Minor
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The version-entries of MANIFEST.MF are important requirements to a couple of 
> frameworks (eclipse, felix, liferay) and specifications (portlets, osgi) in 
> order to load those modules in an consistent way.
> At the moment this deal-breaking configuration of the project is essential in 
> order to create an valid portlet / osgi-modul. Without having the 
> boolean-values as properties we encounter three downsides:
>  # Only using an indispensable dirty mid-size overhead of overriding the 
> MJAR's modul-configuration we can force MJAR to create this essential 
> MANIFEST.MF-entries.
>  # We are unable to early fail the build on missing 
> MANIFEST.MF-version-entries. Even more worse the build will generate invalid 
> osgi/portlets quitting "successfully".
>  # A CI server like Hudson or Jenkins is not able to flange the 
> MANIFEST.MF-version-entries hindsightly.
> Suggestion:
> Be able to direct the generation of version informations like this:
> {quote}{{mvn clean install -Dmaven.addDefaultImplementationEntries=true 
> -Dmaven.addDefaultSpecificationEntries=true}}
> {quote}



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


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

2019-10-31 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-568:
--

That's fine by me. Thank you for the effort!

> 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=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] [Assigned] (WAGON-573) EntityUtils.consumeQuietly() never called on non-2xx status codes

2019-10-30 Thread Michael Osipov (Jira)


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

Michael Osipov reassigned WAGON-573:


Assignee: Michael Osipov

> EntityUtils.consumeQuietly() never called on non-2xx status codes
> -
>
> Key: WAGON-573
> URL: https://issues.apache.org/jira/browse/WAGON-573
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The reponse body in never properly handled if the response is not successful.



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


[jira] [Updated] (WAGON-573) EntityUtils.consumeQuietly() never called on non-2xx status codes

2019-10-30 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-573:
-
Summary: EntityUtils.consumeQuietly() never called on non-2xx status codes  
(was: EntityUtils.consumeQuietly() never called on non-2xx cases)

> EntityUtils.consumeQuietly() never called on non-2xx status codes
> -
>
> Key: WAGON-573
> URL: https://issues.apache.org/jira/browse/WAGON-573
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Michael Osipov
>Priority: Major
>
> The reponse body in never properly handled if the response is not successful.



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


[jira] [Updated] (WAGON-573) EntityUtils.consumeQuietly() never called on non-2xx cases

2019-10-30 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-573:
-
Summary: EntityUtils.consumeQuietly() never called on non-2xx cases  (was: 
EntityUtils.consumeQuetly() never called on non-2xx cases)

> EntityUtils.consumeQuietly() never called on non-2xx cases
> --
>
> Key: WAGON-573
> URL: https://issues.apache.org/jira/browse/WAGON-573
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Michael Osipov
>Priority: Major
>
> The reponse body in never properly handled if the response is not successful.



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


[jira] [Updated] (WAGON-573) EntityUtils.consumeQuetly() never called on non-2xx cases

2019-10-30 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-573:
-
Summary: EntityUtils.consumeQuetly() never called on non-2xx cases  (was: 
EntityUtils.consume() never called on non-2xx cases)

> EntityUtils.consumeQuetly() never called on non-2xx cases
> -
>
> Key: WAGON-573
> URL: https://issues.apache.org/jira/browse/WAGON-573
> Project: Maven Wagon
>  Issue Type: Bug
>Reporter: Michael Osipov
>Priority: Major
>
> The reponse body in never properly handled if the response is not successful.



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


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

2019-10-30 Thread Michael Osipov (Jira)


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

Michael Osipov edited comment on WAGON-568 at 10/30/19 3:22 PM:


My bad, it should have been BAIS. I cannot fully isolate the issue with the 
copy loop, it must be related to the channels and the socket output stream, but 
I was able to modiy a Wagon unit test for this. Please check out from the Wagon 
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see 
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire 
output includes complete wire logging.
The input streams are reused w/o being reset (programming error). HttpClient 
blocks for some reason during read and Jetty issues a {{TimeoutException}} 
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction 
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient 
expect to instantly fail with {{Cannot retry non-repeatable request}} as 
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.


was (Author: michael-o):
My bad, it should have been BAIS. I cannot fully isolate the issue which the 
copy loop, it must be related to the channels and the socket output stream. But 
I was able to modiy a Wagon unit test for this. Please check out from the Wagon 
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see 
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire 
output includes complete wire logging.
The input streams are reusing w/o being reset (programming error). HttpClient 
blocks for some reason during read and Jetty issues a {{TimeoutException}} 
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction 
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient 
expect to instantly fail with {{Cannot retry non-repeatable request}} as 
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.

> 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=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] [Comment Edited] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-30 Thread Michael Osipov (Jira)


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

Michael Osipov edited comment on WAGON-568 at 10/30/19 3:22 PM:


My bad, it should have been BAIS. I cannot fully isolate the issue with the 
copy loop, it must be related to the channels and the socket output stream, but 
I was able to modiy a Wagon unit test for this. Please check out from the Wagon 
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see 
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire 
output includes complete wire logging.
The input streams are reused w/o being reset (programming error). HttpClient 
blocks for some reason during read and Jetty issues a {{TimeoutException}} 
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction 
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient 
expect to instantly fail with {{Cannot retry non-repeatable request}} as 
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.

Before I fix Wagon code, I want to understand why HttpClient blocks here.


was (Author: michael-o):
My bad, it should have been BAIS. I cannot fully isolate the issue with the 
copy loop, it must be related to the channels and the socket output stream, but 
I was able to modiy a Wagon unit test for this. Please check out from the Wagon 
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see 
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire 
output includes complete wire logging.
The input streams are reused w/o being reset (programming error). HttpClient 
blocks for some reason during read and Jetty issues a {{TimeoutException}} 
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction 
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient 
expect to instantly fail with {{Cannot retry non-repeatable request}} as 
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.

> 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=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] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-30 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-568:
--

My bad, it should have been BAIS. I cannot fully isolate the issue which the 
copy loop, it must be related to the channels and the socket output stream. But 
I was able to modiy a Wagon unit test for this. Please check out from the Wagon 
repo branch {{WAGON-568_block}}, run {{mvn clean verify}} and you shall see 
{{HttpWagonTest}#testRedirectPutFromStreamWithFullUrl()} fail. The surefire 
output includes complete wire logging.
The input streams are reusing w/o being reset (programming error). HttpClient 
blocks for some reason during read and Jetty issues a {{TimeoutException}} 
after 30 s. The very same {{writeTo()}} isolated w/o any network interaction 
runs perfectly and returns -1 when the stream is exhausted. I would HttpClient 
expect to instantly fail with {{Cannot retry non-repeatable request}} as 
happens in {{#testRedirectPutFromStreamRelativeUrl()}}.

> 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=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] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-568:
--

[~olegk], I have been chewing on this for quite a while now. The offending code 
is: 
https://github.com/apache/maven-wagon/blob/master/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L177-L229

I can clearly see in a local test that it just blocks the read:

{noformat}
[main] DEBUG org.apache.http.client.protocol.RequestAddCookies - CookieSpec 
selected: compatibility
[main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - 
Connection request: [route: {}->http://localhost:61326][total kept alive: 0; 
route allocated: 0 of 20; total allocated: 0 of 40]
[main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - 
Connection leased: [id: 0][route: {}->http://localhost:61326][total kept alive: 
0; route allocated: 1 of 20; total allocated: 1 of 40]
[main] DEBUG org.apache.http.impl.execchain.MainClientExec - Opening connection 
{}->http://localhost:61326
[main] DEBUG org.apache.http.impl.conn.DefaultHttpClientConnectionOperator - 
Connecting to localhost/127.0.0.1:61326
[main] DEBUG org.apache.http.impl.conn.DefaultHttpClientConnectionOperator - 
Connection established 127.0.0.1:61331<->127.0.0.1:61326
[main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - 
http-outgoing-0: set socket timeout to 180
[main] DEBUG org.apache.http.impl.execchain.MainClientExec - Executing request 
PUT /test-secured-put-resource HTTP/1.1
[main] DEBUG org.apache.http.impl.execchain.MainClientExec - Target auth state: 
UNCHALLENGED
[main] DEBUG org.apache.http.impl.execchain.MainClientExec - Proxy auth state: 
UNCHALLENGED
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> PUT 
/test-secured-put-resource HTTP/1.1
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> Cache-control: 
no-cache
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> Cache-store: no-store
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> Pragma: no-cache
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> Content-Length: 14
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> Host: localhost:61326
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> Connection: Keep-Alive
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> User-Agent: 
Apache-HttpClient/4.5.9 (Java/11.0.1)
[main] DEBUG org.apache.http.headers - http-outgoing-0 >> Accept-Encoding: 
gzip,deflate
call count: 1
Right before read, dst remaining: 4096
 available: 14
Calling read(byte: [B@79179359, int: 0, int: 4096)
Right before read, dst remaining: 4082
 available: 0
Calling read(byte: [B@79179359, int: 0, int: 4082)
[main] DEBUG org.apache.http.headers - http-outgoing-0 << HTTP/1.1 303 See Other
[main] DEBUG org.apache.http.headers - http-outgoing-0 << Date: Tue, 29 Oct 
2019 22:49:38 GMT
[main] DEBUG org.apache.http.headers - http-outgoing-0 << Location: 
/redirectRequest/foo/test-secured-put-resource
[main] DEBUG org.apache.http.headers - http-outgoing-0 << Content-Length: 0
[main] DEBUG org.apache.http.headers - http-outgoing-0 << Server: 
Jetty(9.2.24.v20180105)
[main] DEBUG org.apache.http.impl.execchain.MainClientExec - Connection can be 
kept alive indefinitely
[main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - 
Connection [id: 0][route: {}->http://localhost:61326] can be kept alive 
indefinitely
[main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - 
http-outgoing-0: set socket timeout to 0
[main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - 
Connection released: [id: 0][route: {}->http://localhost:61326][total kept 
alive: 1; route allocated: 1 of 20; total allocated: 1 of 40]
http://localhost:61326/test-secured-put-resource -- status code: 303, reason 
phrase: See Other
 Transfer error: null
Uploading: test-secured-put-resource to http://localhost:61326

[main] DEBUG org.apache.http.client.protocol.RequestAddCookies - CookieSpec 
selected: compatibility
[main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - 
Connection request: [route: {}->http://localhost:61326][total kept alive: 1; 
route allocated: 1 of 20; total allocated: 1 of 40]
[main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - 
Connection leased: [id: 0][route: {}->http://localhost:61326][total kept alive: 
0; route allocated: 1 of 20; total allocated: 1 of 40]
call count: 2
Right before read, dst remaining: 4096
 available: 0
Calling read(byte: [B@4fad9bb2, int: 0, int: 4096)
[main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - 
http-outgoing-0: set socket timeout to 0
[main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - 
http-outgoing-0: set socket timeout to 

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

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-568:
--

I can reproduce the lockup/stall with 
{{testRedirectPutFromStreamRelativeUrl(org.apache.maven.wagon.providers.http.HttpWagonTest)}}
 when I switch from {{FileInputStream}} to {{ByteArrayInputStream}}.

> 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=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] [Closed] (WAGON-567) Provide request retry strategy on transient client and server side errors

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov closed WAGON-567.

Resolution: Fixed

Fixed with 
[49c3537e1e1541538013c376e5ac57b09a3ec230|https://gitbox.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=49c3537e1e1541538013c376e5ac57b09a3ec230].

> Provide request retry strategy on transient client and server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Updated] (WAGON-567) Provide request retry strategy on client and server side errors

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-567:
-
Summary: Provide request retry strategy on client and server side errors  
(was: Provide download retry strategy on client and server side errors)

> Provide request retry strategy on client and server side errors
> ---
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Updated] (WAGON-567) Provide request retry strategy on transient client and server side errors

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-567:
-
Summary: Provide request retry strategy on transient client and server side 
errors  (was: Provide request retry strategy on client and server side errors)

> Provide request retry strategy on transient client and server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Updated] (WAGON-567) Provide download retry strategy on client and server side errors

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-567:
-
Summary: Provide download retry strategy on client and server side errors  
(was: Wagon should retry download on client and server side errors)

> Provide download retry strategy on client and server side errors
> 
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Updated] (WAGON-567) Wagon should retry download on client and server side errors

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-567:
-
Summary: Wagon should retry download on client and server side errors  
(was: Wagon should retry download on server side errors)

> Wagon should retry download on client and server side errors
> 
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Closed] (WAGON-571) Rename RequestEntityImplementation to WagonHttpEntity

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov closed WAGON-571.

Resolution: Fixed

Fixed with 
[cd2acb158a531bf555c752da650551671171b0a5|https://gitbox.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=cd2acb158a531bf555c752da650551671171b0a5].

> Rename RequestEntityImplementation to WagonHttpEntity
> -
>
> Key: WAGON-571
> URL: https://issues.apache.org/jira/browse/WAGON-571
> Project: Maven Wagon
>  Issue Type: Task
>  Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.4
>
>
> Give this private class a better name because because it plays a key role 
> during up/download.



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


[jira] [Assigned] (WAGON-571) Rename RequestEntityImplementation to WagonHttpEntity

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov reassigned WAGON-571:


Assignee: Michael Osipov

> Rename RequestEntityImplementation to WagonHttpEntity
> -
>
> Key: WAGON-571
> URL: https://issues.apache.org/jira/browse/WAGON-571
> Project: Maven Wagon
>  Issue Type: Task
>  Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Give this private class a better name because because it plays a key role 
> during up/download.



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


[jira] [Updated] (WAGON-571) Rename RequestEntityImplementation to WagonHttpEntity

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-571:
-
Fix Version/s: 3.3.4

> Rename RequestEntityImplementation to WagonHttpEntity
> -
>
> Key: WAGON-571
> URL: https://issues.apache.org/jira/browse/WAGON-571
> Project: Maven Wagon
>  Issue Type: Task
>  Components: wagon-http
>Affects Versions: 3.3.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.4
>
>
> Give this private class a better name because because it plays a key role 
> during up/download.



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


[jira] [Closed] (WAGON-569) Inconsistent encoding behavior for repository URLs with spaces

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov closed WAGON-569.

Resolution: Fixed

Fixed with 
[7d1315e47df948d8b17f5c759b20a5b3437cbff7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git;a=commit;h=7d1315e47df948d8b17f5c759b20a5b3437cbff7].

> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.4
>
> Attachments: debug-log-2019-10-16-2.txt, debug-log-2019-10-16.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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] [Commented] (MNG-6796) 30 min guide first command doesn't work in commandline windows

2019-10-29 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6796:
-

The examples implies Unix shell line continuations. Windows uses {{^}}. Did you 
try that?

> 30 min guide first command doesn't work in commandline windows
> --
>
> Key: MNG-6796
> URL: https://issues.apache.org/jira/browse/MNG-6796
> Project: Maven
>  Issue Type: Bug
> Environment: windows command line
>Reporter: Roman Korver
>Priority: Trivial
>
> I tried to walk through the 30 min guide:
> [https://maven.apache.org/guides/getting-started/index.html]
> And stumbled on an issue after entering the first ":generate" command 
>  # mvn -B archetype:generate \
>  # -DarchetypeGroupId=org.apache.maven.archetypes \
>  # -DgroupId=com.mycompany.app \
>  # -DartifactId=my-app
> I entered it (without the numbers of course), in the windows command line.
> C:\Users\rkorver\Documents\GitHub\maven-practice>mvn -B archetype:generate \ 
> -DarchetypeGroupID=org.apache.maven.archetypes \ -DgroupID=com.mycompany.app 
> \ -DartifactId=my-app
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 0.123 s
> [INFO] Finished at: 2019-10-28T16:30:18+01:00
> [INFO] 
> 
> [ERROR] The goal you specified requires a project to execute but there is no 
> POM in this directory (C:\Users\rkorver\Documents\GitHub\maven-practice). 
> Please verify you invoked Maven from the correct directory. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MissingProjectException
> (this ^ link is not helpful in this case) 
>  
>  * This command, in the 5 min guide works fine however! 
> mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app 
> -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 
> -DinteractiveMode=false
>  
> A hint I found in one of my tries: 
> [WARNING] Property groupId is missing. Add -DgroupId=someValue
> {color:#FF}[WARNING] Property package is missing. Add 
> -Dpackage=someValue{color}
> {color:#172b4d}could that last one be the real issue?{color}
> {color:#172b4d}*As a* beginner user of Maven, {color}
> *Want* the beginner guide fixed
> *So* other beginner Maven users aren't unnecessarily frustrated.
>  
>  



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


[jira] [Created] (WAGON-573) EntityUtils.consume() never called on non-2xx cases

2019-10-28 Thread Michael Osipov (Jira)
Michael Osipov created WAGON-573:


 Summary: EntityUtils.consume() never called on non-2xx cases
 Key: WAGON-573
 URL: https://issues.apache.org/jira/browse/WAGON-573
 Project: Maven Wagon
  Issue Type: Bug
Reporter: Michael Osipov


The reponse body in never properly handled if the response is not successful.



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


[jira] [Created] (WAGON-572) Mark ByteArrayInputStream in RequestEntityImplementation as repeatable

2019-10-28 Thread Michael Osipov (Jira)
Michael Osipov created WAGON-572:


 Summary: Mark ByteArrayInputStream in RequestEntityImplementation 
as repeatable
 Key: WAGON-572
 URL: https://issues.apache.org/jira/browse/WAGON-572
 Project: Maven Wagon
  Issue Type: Improvement
  Components: wagon-http
Affects Versions: 3.3.3
Reporter: Michael Osipov


There are cases where a request needs to be replayed. Input treams aren't 
repeatable by nature, but those based on byte arrays are. Our signature 
calculation spits out strings, byte arrays. Handle byte arrays as we handle 
{{FileInputStreams}}.



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


[jira] [Created] (WAGON-571) Rename RequestEntityImplementation to WagonHttpEntity

2019-10-28 Thread Michael Osipov (Jira)
Michael Osipov created WAGON-571:


 Summary: Rename RequestEntityImplementation to WagonHttpEntity
 Key: WAGON-571
 URL: https://issues.apache.org/jira/browse/WAGON-571
 Project: Maven Wagon
  Issue Type: Task
  Components: wagon-http
Affects Versions: 3.3.3
Reporter: Michael Osipov


Give this private class a better name because because it plays a key role 
during up/download.



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


[jira] [Created] (WAGON-570) Use RedirectStrategy from HttpClient rather than our custom code

2019-10-28 Thread Michael Osipov (Jira)
Michael Osipov created WAGON-570:


 Summary: Use RedirectStrategy from HttpClient rather than our 
custom code
 Key: WAGON-570
 URL: https://issues.apache.org/jira/browse/WAGON-570
 Project: Maven Wagon
  Issue Type: Improvement
  Components: wagon-http
Affects Versions: 3.3.3
Reporter: Michael Osipov


We have a custom implementation where we follow relocations for status codes 
3xx. We can leverage {{RedirectStrategy}} implementations instead doing this on 
our own.



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


[jira] [Comment Edited] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov edited comment on MNG-6795 at 10/27/19 8:41 PM:
---

It is also to mention that only a few servers allow to set the reason phrase. 
Tomcat never supported it. Other likely neither. See also [Undertow's 
documentation on 
it|http://undertow.io/javadoc/1.3.x/io/undertow/server/HttpServerExchange.html#setReasonPhrase-java.lang.String-].
 I think the resolution of WAGON-541 is just wrong.


was (Author: michael-o):
It is also to mention that only a few servers allow to set the reason phrase. 
Tomcat never supported it. Other likely neither. See also [Undertow's 
documentation on 
it](http://undertow.io/javadoc/1.3.x/io/undertow/server/HttpServerExchange.html#setReasonPhrase-java.lang.String-).
 I think the resolution of WAGON-541 is just wrong.

> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in 
> HTTP/1.1 for more than five years. It is useful to give detailed error 
> messages on artifact transfert errors with a repository manager.
> A replacement has to be found



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


[jira] [Commented] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6795:
-

It is also to mention that only a few servers allow to set the reason phrase. 
Tomcat never supported it. Other likely neither. See also [Undertow's 
documentation on 
it](http://undertow.io/javadoc/1.3.x/io/undertow/server/HttpServerExchange.html#setReasonPhrase-java.lang.String-).
 I think the resolution of WAGON-541 is just wrong.

> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in 
> HTTP/1.1 for more than five years. It is useful to give detailed error 
> messages on artifact transfert errors with a repository manager.
> A replacement has to be found



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


[jira] [Commented] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6795:
-

I don't see this to be realistically implemented. It will take years to take 
over.

> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2
> it is useful to give detailed error messages on artifact transfert errors 
> with a repository manager
> A replacement has to be found



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


[jira] [Updated] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated MNG-6795:

Description: 
as documented in WAGON-541 
[372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
 ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in 
HTTP/1.1 for more than five years. It is useful to give detailed error messages 
on artifact transfert errors with a repository manager.
A replacement has to be found

  was:
as documented in WAGON-541 
[372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
 ReasonPhrase has been removed from HTTP/2
it is useful to give detailed error messages on artifact transfert errors with 
a repository manager
A replacement has to be found


> define a replacement for ReasonPhrase to display details about transfert 
> failures
> -
>
> Key: MNG-6795
> URL: https://issues.apache.org/jira/browse/MNG-6795
> Project: Maven
>  Issue Type: Task
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.6.3
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> as documented in WAGON-541 
> [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7],
>  ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in 
> HTTP/1.1 for more than five years. It is useful to give detailed error 
> messages on artifact transfert errors with a repository manager.
> A replacement has to be found



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


[jira] [Updated] (MNG-6794) Add mvn add groupId/artifactId feature like NPM to maven

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated MNG-6794:

Priority: Minor  (was: Major)

> Add mvn add groupId/artifactId feature like NPM to maven
> 
>
> Key: MNG-6794
> URL: https://issues.apache.org/jira/browse/MNG-6794
> Project: Maven
>  Issue Type: Wish
>Reporter: gaurav
>Priority: Minor
>
> The article 10 myths about java in 
> 2019(https://developer.okta.com/blog/2019/07/15/java-myths-2019) list a nice 
> feature which maven could add to it.
>  
> For NPM, Want to add a new dependency? Just run {{npm i groupId/artifactId}}.
>  
> do think it would be cool if Maven had something like {{mvn add 
> groupId/artifactId}}



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


[jira] [Commented] (WAGON-566) Add support for URI normalization

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-566:
--

[~stvricbr...@gmail.com], are you willing to try a patch?

> Add support for URI normalization
> -
>
> 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
>   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)


[jira] [Updated] (WAGON-569) Inconsistent encoding behavior for repository URLs with spaces

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-569:
-
Summary: Inconsistent encoding behavior for repository URLs with spaces  
(was: Inconsistent encoding behavior for repository urls with spaces)

> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.4
>
> 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] [Updated] (WAGON-566) Add support for URI normalization

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-566:
-
Summary: Add support for URI normalization  (was: Fix for MSITE-738)

> Add support for URI normalization
> -
>
> 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
>   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)


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

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-569:
-
Fix Version/s: (was: waiting-for-feedback)
   3.3.4

> 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
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.3.4
>
> 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] [Assigned] (WAGON-569) Inconsistent encoding behavior for repository urls with spaces

2019-10-27 Thread Michael Osipov (Jira)


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

Michael Osipov reassigned WAGON-569:


Assignee: Michael Osipov

> 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
>Assignee: Michael Osipov
>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] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

2019-10-24 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-541:
--

[~brianf], I'd concur that in 95%+ the reason phrase will not contain any 
better help that then status code itself.

[~hboutemy], I'd evaluate something more standardized like 
{{application/problem+json}} if it makes sense before we roll our own error 
format.

> Command Line Not Showing ReasonPhrase for Errors
> 
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, 
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we 
> provide a Maven service to our customers. We often use a Reason-Phrase to 
> return information on failed requests to customers. This functionality was 
> available in previous versions of maven but seems to have disappeared in 
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different 
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would 
> return a 405 error to be able to get an error response. I also used the same 
> package.
> Thanks



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


[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

2019-10-24 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-541:
--

I am referring to the RFC 7230, plain simple. It clearly says the client (Maven 
here) should ignore and there is nothing wrong to do so. Please read section 
3.1.2. HTTP/2 completely dropped the phrase anyway.

> Command Line Not Showing ReasonPhrase for Errors
> 
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, 
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we 
> provide a Maven service to our customers. We often use a Reason-Phrase to 
> return information on failed requests to customers. This functionality was 
> available in previous versions of maven but seems to have disappeared in 
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different 
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would 
> return a 405 error to be able to get an error response. I also used the same 
> package.
> Thanks



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


[jira] [Commented] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project

2019-10-24 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6793:
-

You would drastically reduce the download time.

> Sharing local repo for dependencies and a separate local repo for project
> -
>
> Key: MNG-6793
> URL: https://issues.apache.org/jira/browse/MNG-6793
> Project: Maven
>  Issue Type: Wish
>  Components: Bootstrap  Build
>Reporter: Daniel Qian
>Priority: Minor
>  Labels: features
>
> When I use Jenkins to build project I have to make each Job to use its own 
> local repo (a local dir in the workspace) to prevent concurrent build error:
> {{withMaven(}}
> {{  mavenLocalRepo: '.local-m2-repo'}}
> {{) {}}
> {{ sh 'mvn clean install -P docker,integration-test'}}
> {{ }}}
> Besides, I have to cleanup workspace after build to save disk space.
> So every time the build starts it have to download all the dependencies and 
> that really cost a lot of time.
> So I think it will be nice If maven could share a local repo for dependencies 
> and a separate local repo for current built project.
> Then we can save time of download dependencies and also provide isolation to 
> prevent concurrent build error.



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


[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors

2019-10-24 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-541:
--

Citing from RFC 7230, *2014-06*:

bq. A client SHOULD ignore the reason-phrase content.

So folks, you had five years to get used to it.

> Command Line Not Showing ReasonPhrase for Errors
> 
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, 
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we 
> provide a Maven service to our customers. We often use a Reason-Phrase to 
> return information on failed requests to customers. This functionality was 
> available in previous versions of maven but seems to have disappeared in 
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different 
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would 
> return a 405 error to be able to get an error response. I also used the same 
> package.
> Thanks



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


[jira] [Commented] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore

2019-10-24 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6584:
-

Citing from RFC 7230, *2014-06*:

bq. A client SHOULD ignore the reason-phrase content.

So folks, you had five years to get used to it.

> Maven version 3.6.0 does not show ReasonPhrase anymore
> --
>
> Key: MNG-6584
> URL: https://issues.apache.org/jira/browse/MNG-6584
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Lucas Ludueño
>Priority: Major
> Fix For: 3.6.3, 3.6.x-candidate
>
>
> Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for 
> example when you run mvn deploy to a custom Maven service).
> With version 3.5.0 the ReasonPhrase is shown in a message like:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on 
> project mule-module-tooling-service: Failed to deploy artifacts: Could not 
> transfer artifact 
> 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3
>  from/to exchange-repository 
> (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to 
> transfer file: 
> http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar.
>  Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1]
> I am not completely sure if the ReasonPhrase has been removed intentionally. 
> If the answer is no, can you fix it? If the answer is yes, how can I simulate 
> the behavior to indicate to someone what was happening?
>  
> Thanks!!
>  



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


[jira] [Commented] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project

2019-10-24 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6793:
-

Please use a local Nexus instance for that. Do you have one?

> Sharing local repo for dependencies and a separate local repo for project
> -
>
> Key: MNG-6793
> URL: https://issues.apache.org/jira/browse/MNG-6793
> Project: Maven
>  Issue Type: Wish
>  Components: Bootstrap  Build
>Reporter: Daniel Qian
>Priority: Minor
>  Labels: features
>
> When I use Jenkins to build project I have to make each Job to use its own 
> local repo (a local dir in the workspace) to prevent concurrent build error:
> {{withMaven(}}
> {{  mavenLocalRepo: '.local-m2-repo'}}
> {{) {}}
> {{ sh 'mvn clean install -P docker,integration-test'}}
> {{ }}}
> Besides, I have to cleanup workspace after build to save disk space.
> So every time the build starts it have to download all the dependencies and 
> that really cost a lot of time.
> So I think it will be nice If maven could share a local repo for dependencies 
> and a separate local repo for current built project.
> Then we can save time of download dependencies and also provide isolation to 
> prevent concurrent build error.



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


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

2019-10-23 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-566:
--

[~olegk], I will work on that. This won't be on by default.

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


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

2019-10-23 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-566:
--

Alright, this is exactly what I wanted to do. I am still thinking whether this 
would another system properly or could be set on a request basis. Version 4.5.9 
sets normalizeUri by default. Won't this happily solve this issue? Or will a 
simple {{URI#normalize()}} do?

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


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

2019-10-23 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-566:
-
Fix Version/s: (was: 3.3.4)

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


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

2019-10-23 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-566:
--

Thanks, so from your POV, this is not a client issue at all. The URI sent here 
is fully valid, e.g., 
{{https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64/../../pool/9ff2e28300e012e2b692e1d4445786f0bed0fd5c13ef650d61369097bfdd0519-kubectl-1.10.0-0.x86_64.rpm}}.

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


[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=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)


[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] [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)


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

2019-10-21 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-568:
--

Did you get a chance to run the build with the subsequent changes? Can you also 
provide a debug log with the previously working upload please?

> 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=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] [Moved] (WAGON-568) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-21 Thread Michael Osipov (Jira)


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

Michael Osipov moved MNG-6785 to WAGON-568:
---

  Component/s: (was: Deployment)
   wagon-http
Fix Version/s: (was: waiting-for-feedback)
  Key: WAGON-568  (was: MNG-6785)
Affects Version/s: (was: 3.6.2)
   (was: 3.5.4)
   3.3.3
  Project: Maven Wagon  (was: Maven)

> 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=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] (MDEPLOY-261) Inconsistent encoding behavior for repository urls with spaces

2019-10-21 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956329#comment-16956329
 ] 

Michael Osipov commented on MDEPLOY-261:


Did you get a chance to test that?

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: MDEPLOY-261
> URL: https://issues.apache.org/jira/browse/MDEPLOY-261
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> 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] [Updated] (MINSTALL-162) Add GitHub Information

2019-10-19 Thread Michael Osipov (Jira)


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

Michael Osipov updated MINSTALL-162:

Summary: Add GitHub Information  (was: Add GitHub Informations)

> Add GitHub Information
> --
>
> Key: MINSTALL-162
> URL: https://issues.apache.org/jira/browse/MINSTALL-162
> Project: Maven Install Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.0.0
>
>




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


[jira] [Commented] (MPIR-374) Unknown packaging: bundle when creating report

2019-10-19 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MPIR-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955181#comment-16955181
 ] 

Michael Osipov commented on MPIR-374:
-

[~bmaehr], I have tried to do a release. Issues popped up which required to 
cancel the vote. I won't rerun it due to time issues. Maybe somenoe else can. 
Write to the dev mailing list.

> Unknown packaging: bundle when creating report
> --
>
> Key: MPIR-374
> URL: https://issues.apache.org/jira/browse/MPIR-374
> Project: Maven Project Info Reports Plugin
>  Issue Type: Bug
>  Components: dependency-management
>Affects Versions: 3.0.0
> Environment: Java 10
>Reporter: Peter Lamby
>Priority: Minor
>
> After I upgraded the plugin to 3.0.0 I get the following errors:
> {noformat}
> [INFO] Generating "Dependency Management" report --- 
> maven-project-info-reports-plugin:3.0.0:dependency-management
> [WARNING] Unable to create Maven project for 
> com.fasterxml.jackson.module:jackson-module-scala_2.10:jar:2.9.5 from 
> repository.
> org.apache.maven.project.ProjectBuildingException: Some problems were 
> encountered while processing the POMs:
> [ERROR] Unknown packaging: bundle @ line 6, column 16
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:192)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:327)
>   at 
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository(RepositoryUtils.java:125)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.getDependencyRow(DependencyManagementRenderer.java:253)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForScope(DependencyManagementRenderer.java:202)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderDependenciesForAllScopes(DependencyManagementRenderer.java:151)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderSectionProjectDependencies(DependencyManagementRenderer.java:144)
>   at 
> org.apache.maven.report.projectinfo.dependencies.renderer.DependencyManagementRenderer.renderBody(DependencyManagementRenderer.java:130)
>   at 
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:80)
>   at 
> org.apache.maven.report.projectinfo.DependencyManagementReport.executeReport(DependencyManagementReport.java:107)
>   at 
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:251)
>   at 
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:230)
>   at 
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:349)
>   at 
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:198)
>   at 
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:147)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:564)
>   at 
> 

[jira] [Updated] (WAGON-567) Wagon should retry download on server side errors

2019-10-18 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-567:
-
Fix Version/s: (was: waiting-for-feedback)
   3.3.4

> Wagon should retry download on server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.3.4
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Assigned] (WAGON-567) Wagon should retry download on server side errors

2019-10-18 Thread Michael Osipov (Jira)


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

Michael Osipov reassigned WAGON-567:


Assignee: Michael Osipov

> Wagon should retry download on server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: waiting-for-feedback
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L393]
>  and [httpclient 
> source|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90],
>  [httpclient default retry 
> handler|https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.java#L154].
>  However,  it only captures low level connection issues. When the repo 
> returns errors like 500 or 503, it does not retry. The 5xx response from the 
> repo might be a blip and maven should retry before giving up.



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


[jira] [Commented] (MNG-6765) [Regression] tycho pom-less builds fails with 3.6.2

2019-10-18 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6765:
-

Before we revert then offending commit I'd second Hervé's approach.

> [Regression] tycho pom-less builds fails with 3.6.2
> ---
>
> Key: MNG-6765
> URL: https://issues.apache.org/jira/browse/MNG-6765
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Jonathan Chen
>Priority: Critical
>
> Projects using tycho pom-less builds fail with maven-3.6.2.
> One such example would be using maven-3.6.2 to build Eclipse-4.13, which 
> fails pretty early in the build with:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> input contained no data @
> ...
> {noformat}
> These errors do not arise with maven-3.6.0 or maven-3.6.1



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


[jira] [Commented] (MDEPLOY-261) Inconsistent encoding behavior for repository urls with spaces

2019-10-16 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953189#comment-16953189
 ] 

Michael Osipov commented on MDEPLOY-261:


I have uploaded the branch {{uri-encoding}} for Wagon. Rebuild Wagon and 
rebuild Mavn 3.5.3-SNAPSHOT with the SNAPSHOT of Wagon and rerun the build with 
debug logs enabled.

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: MDEPLOY-261
> URL: https://issues.apache.org/jira/browse/MDEPLOY-261
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> 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] [Commented] (MDEPLOY-261) Inconsistent encoding behavior for repository urls with spaces

2019-10-16 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953157#comment-16953157
 ] 

Michael Osipov commented on MDEPLOY-261:


I think I have found the issue, stupidest thing ever. Are you willing to try a 
patch?

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: MDEPLOY-261
> URL: https://issues.apache.org/jira/browse/MDEPLOY-261
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> 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] [Commented] (MDEPLOY-261) Inconsistent encoding behavior for repository urls with spaces

2019-10-16 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953149#comment-16953149
 ] 

Michael Osipov commented on MDEPLOY-261:


Looking into it. Please try Maven 3.6.2.

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: MDEPLOY-261
> URL: https://issues.apache.org/jira/browse/MDEPLOY-261
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> 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] [Commented] (MDEPLOY-261) Inconsistent encoding behavior for repository urls with spaces

2019-10-16 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953137#comment-16953137
 ] 

Michael Osipov commented on MDEPLOY-261:


https://github.com/apache/maven/blob/master/apache-maven/src/conf/logging/simplelogger.properties#L30-L32

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: MDEPLOY-261
> URL: https://issues.apache.org/jira/browse/MDEPLOY-261
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> 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.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] [Commented] (MDEPLOY-261) Inconsistent encoding behavior for repository urls with spaces

2019-10-16 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16953110#comment-16953110
 ] 

Michael Osipov commented on MDEPLOY-261:


Please also enable header debug logs on the HttpClient.

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: MDEPLOY-261
> URL: https://issues.apache.org/jira/browse/MDEPLOY-261
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> 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.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] [Updated] (MDEPLOY-261) Inconsistent encoding behavior for repository urls with spaces

2019-10-16 Thread Michael Osipov (Jira)


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

Michael Osipov updated MDEPLOY-261:
---
Fix Version/s: waiting-for-feedback

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: MDEPLOY-261
> URL: https://issues.apache.org/jira/browse/MDEPLOY-261
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> 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
>
>
> 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] [Commented] (MDEPLOY-261) Inconsistent encoding behavior for repository urls with spaces

2019-10-16 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MDEPLOY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952859#comment-16952859
 ] 

Michael Osipov commented on MDEPLOY-261:


Please provide full debug log of the HttpClient installed with Maven.

> Inconsistent encoding behavior for repository urls with spaces
> --
>
> Key: MDEPLOY-261
> URL: https://issues.apache.org/jira/browse/MDEPLOY-261
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> 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
>
> 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] [Commented] (MNG-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-16 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

This is how this should look like:

{noformat}
[main] DEBUG org.apache.http.wire - http-outgoing-0 >> "POST 
/~osipovmi/redirect.php HTTP/1.1[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 >> "Transfer-Encoding: 
chunked[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 >> "Host: 
deblndw011x.ad001.siemens.net[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 >> "Connection: 
Keep-Alive[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 >> "User-Agent: 
Apache-HttpClient/4.5.6 (Java/1.8.0_212)[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 >> "Expect: 
100-continue[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 >> "Accept-Encoding: 
gzip,deflate[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 >> "[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "HTTP/1.1 307 Temporary 
Redirect[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "Date: Wed, 16 Oct 2019 
13:41:06 GMT[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "Server: Apache/2.4.41 
(FreeBSD) OpenSSL/1.1.1c-freebsd PHP/7.2.22 SVN/1.10.6 
mod_auth_gssapi/1.6.1[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "X-Frame-Options: 
SAMEORIGIN[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "X-Powered-By: 
PHP/7.2.22[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "Location: 
/~osipovmi/CONNECTORS-1564.php[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "Content-Length: 
0[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "Connection: 
close[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "Content-Type: 
text/html; charset=UTF-8[\r][\n]"
[main] DEBUG org.apache.http.wire - http-outgoing-0 << "[\r][\n]"
{noformat}

I have written standalone code which duplicates the code from Wagon. I cannot 
replicate the lockup with HTTPd 2.4.41 and a PHP script.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-16 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

[~kalished], I have pushed a subsequent commit which will give us some data. 
Please rerun and post that output data from stdout.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-16 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

There are several issues here and you also don't need to reveal all of your 
data, only at most I need to see if they are not confidential. Don't worry.

First and foremost, the expect continue is correctly implemented in HttpClient, 
but broken in the server side.

Look at this dump. The clients says {{Expect: 100-continue}} and the servers 
says {{HTTP/1.1 100 Continue}}, the payload 
{{39aa049118761a5e1d1a3788ea994201}} is trasmitted, but then {{HTTP/1.1 301 
Moved Permanently}} is issued which requires another request. Unfortnately, as 
layed out previously the checkput input stream has already been consumed. It 
cannot be replayed. The server should have returned {{HTTP/1.1 301 Moved 
Permanently}} immediately and not after the {{HTTP/1.1 301 Moved Permanently}}. 
The reason for this is that 
{{HTTP/1.1 100 Continue}} comes from Jetty, but {{HTTP/1.1 301 Moved 
Permanently}} from application code. Jetty does not know that upfront. It is 
deemed to fail.

{noformat}
 [DEBUG] http-outgoing-2 >> "PUT 
/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.41/async-http-client-project-2.0.41.pom.md5
 HTTP/1.1[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Cache-control: no-cache[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Cache-store: no-store[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Pragma: no-cache[\r][\n]"
 [DEBUG] http-outgoing-2 >> "User-Agent: Apache-Maven/3.6.3-SNAPSHOT (Java 
1.8.0_202; Mac OS X 10.13.6)[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Content-Length: 32[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Host: oss.sonatype.org[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Connection: Keep-Alive[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Expect: 100-continue[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Accept-Encoding: gzip,deflate[\r][\n]"
 [DEBUG] http-outgoing-2 >> "Authorization: Basic REDACTED[\r][\n]"
 [DEBUG] http-outgoing-2 >> "[\r][\n]"
 [DEBUG] http-outgoing-2 << "HTTP/1.1 100 Continue[\r][\n]"
 [DEBUG] http-outgoing-2 << "[\r][\n]"
 [DEBUG] http-outgoing-2 << HTTP/1.1 100 Continue
 [DEBUG] http-outgoing-2 >> "39aa049118761a5e1d1a3788ea994201"
 [DEBUG] http-outgoing-2 << "HTTP/1.1 301 Moved Permanently[\r][\n]"
 [DEBUG] http-outgoing-2 << "Server: awselb/2.0[\r][\n]"
 [DEBUG] http-outgoing-2 << "Date: Wed, 16 Oct 2019 08:11:28 GMT[\r][\n]"
 [DEBUG] http-outgoing-2 << "Content-Type: text/html[\r][\n]"
 [DEBUG] http-outgoing-2 << "Content-Length: 150[\r][\n]"
 [DEBUG] http-outgoing-2 << "Connection: keep-alive[\r][\n]"
 [DEBUG] http-outgoing-2 << "Location: 
https://oss.sonatype.org:443/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.41/async-http-client-project-2.0.41.pom.md5[\r][\n];
 [DEBUG] http-outgoing-2 << "[\r][\n]"
 [DEBUG] http-outgoing-2 << "[\r][\n]"
 [DEBUG] http-outgoing-2 << "301 Moved 
Permanently[\r][\n]"
 [DEBUG] http-outgoing-2 << "[\r][\n]"
 [DEBUG] http-outgoing-2 << "301 Moved 
Permanently[\r][\n]"
 [DEBUG] http-outgoing-2 << "[\r][\n]"
 [DEBUG] http-outgoing-2 << "[\r][\n]"
{noformat}

Let's look at the next issue, previously our buffering was dumb. Me moved to 
buffering with channels. The channel tried to read from a stream which has been 
consumed and closed already, and therefore locks up. The issue did not pop up 
because the buggy code has never been triggered.

We blindly replay the request w/o even knowning is our {{HttpEntity}} 
replayable. Let me try something and we'll see.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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: 
> 

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

2019-10-16 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

Alright, the checksum will do the  
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L610-L619|following]
 which will result in a 
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/transport/PutTask.java#L60-L67|{{ByteArrayInputStream}}]
 and the intended to be 
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-wagon/src/main/java/org/eclipse/aether/transport/wagon/WagonTransporter.java#L655-L680|streamed].
 {{AbstractHttpClientWagon}} has its own {{HttpEntity}} impl which will mark it 
as non-repeatable as soon as in {{InputStream}} is passed.

I will add some debug some to prove my assumption. There are several ways to 
fix this, but one -- imho -- w/o changing the API.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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] [Comment Edited] (MNG-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-16 Thread Michael Osipov (Jira)


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

Michael Osipov edited comment on MNG-6785 at 10/16/19 11:11 AM:


Alright, the checksum will do the  
[following|https://github.com/apache/maven-resolver/blob/master/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L610-L619]
 which will result in a 
[{{ByteArrayInputStream}}|https://github.com/apache/maven-resolver/blob/master/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/transport/PutTask.java#L60-L67]
 and the intended to be 
[streamed|https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-wagon/src/main/java/org/eclipse/aether/transport/wagon/WagonTransporter.java#L655-L680].
 {{AbstractHttpClientWagon}} has its own {{HttpEntity}} impl which will mark it 
as non-repeatable as soon as in {{InputStream}} is passed.

I will add some debug some to prove my assumption. There are several ways to 
fix this, but one -- imho -- w/o changing the API.


was (Author: michael-o):
Alright, the checksum will do the  
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/BasicRepositoryConnector.java#L610-L619|following]
 which will result in a 
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/transport/PutTask.java#L60-L67|{{ByteArrayInputStream}}]
 and the intended to be 
[https://github.com/apache/maven-resolver/blob/master/maven-resolver-transport-wagon/src/main/java/org/eclipse/aether/transport/wagon/WagonTransporter.java#L655-L680|streamed].
 {{AbstractHttpClientWagon}} has its own {{HttpEntity}} impl which will mark it 
as non-repeatable as soon as in {{InputStream}} is passed.

I will add some debug some to prove my assumption. There are several ways to 
fix this, but one -- imho -- w/o changing the API.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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] [Comment Edited] (MNG-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-16 Thread Michael Osipov (Jira)


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

Michael Osipov edited comment on MNG-6785 at 10/16/19 9:35 AM:
---

OK, please also upload the Maven output itself. I'd like to see how the upload 
progress looks like now.
I think I know what the cause might be. We have exactly one {{Location: 
https://oss.sonatype.org:443/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.41/async-http-client-project-2.0.41.pom.md5}}
 and the second one stalls. This is highly likely a bug in Maven Resolver where 
the {{HttpEntity}} might now be repeatable or has been already destroyed 
because I have closed the previous put. Either way, it is a short coming. Let 
me have a look at this and get back to you.

If this cannot be solve reasonably, we must desupport relocations unfortunately.


was (Author: michael-o):
OK, please also upload the Maven output itself. I'd like to see how the upload 
progress looks like now.
I think I know what the cause might be. We have exactly one {{Location: 
https://oss.sonatype.org:443/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.41/async-http-client-project-2.0.41.pom.md5}}
 and the second one stalls. This is highly likely a bug in Maven Resolver where 
the {{HttpEntity} might now be repeatable or has been already destroyed because 
I have closed the previous put. Either way, it is a short coming. Let me have a 
look at this and get back to you.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-16 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

OK, please also upload the Maven output itself. I'd like to see how the upload 
progress looks like now.
I think I know what the cause might be. We have exactly one {{Location: 
https://oss.sonatype.org:443/service/local/staging/deploy/maven2/org/asynchttpclient/async-http-client-project/2.0.41/async-http-client-project-2.0.41.pom.md5}}
 and the second one stalls. This is highly likely a bug in Maven Resolver where 
the {{HttpEntity} might now be repeatable or has been already destroyed because 
I have closed the previous put. Either way, it is a short coming. Let me have a 
look at this and get back to you.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp

2019-10-15 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952081#comment-16952081
 ] 

Michael Osipov commented on MSHARED-837:


[~hboutemy], I have added a subsequent commit with the discussed changes.

> add an API to configure Reproducible Builds with outputTimestamp
> 
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure 
> archiver with an output timestamp: see 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because 
> Plexus Date injection uses local timezone, then is not reproducible: see 
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and 
> provide an API to parse this String to a Date, before calling 
> plexus-archiver's configureReproducible 
> https://github.com/codehaus-plexus/plexus-archiver/pull/121



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


[jira] [Commented] (MNG-6784) Create correct SHA512 content

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6784:
-

I concur to change this. Because this will deviate from the general habit we 
provide checksum files. They contain the checksum only. There is no canoncial 
checksum file format.

> Create correct SHA512 content
> -
>
> Key: MNG-6784
> URL: https://issues.apache.org/jira/browse/MNG-6784
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.3
>
>
> Currently the created SHA512 which is used for the distribution area contains 
> only the checksum but not the filename which results in bad output if the 
> checksums being checked via command line tool:
> {code}
> $ shasum -c apache-maven-3.2.5-bin.tar.gz.sha512
> $ shasum: apache-maven-3.2.5-bin.tar.gz.sha512: no properly formatted SHA 
> checksum lines found
> {code}
> The checksum should be enhanced to support that correctly.



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


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

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

Embarrasing, I pushed w/o committed first. All is there, HEAD points now to 
https://github.com/apache/maven-wagon/commit/909cf6dfab79ddfdaa6bed7e97b7e99471a66fda.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

I actually tried with http and did not receive the redirect or simply wasn't 
able to trigger the IAE. Don't know why. At best, this is a decent unit test 
for this problem with Wagon.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

The root cause is that one cannot mark redirect as internal requests to reset 
events or reset transferred bytes count. I have created branch {{redirect-iae}} 
with Wagon which combines several fixes. Please compile Wagon from this branch 
and rebuild Maven with this updated version. Then retry.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

Even if you change to https, the bugs remains present. Are you willing to try 
patched version of Maven wagon? I -- sort of -- know how one can fix that. Not 
perfect solution, but a good one.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

The issue is quite obvious that the TransferTransportListener does not reset 
the event log when Maven issues another manual request to follow redirects 
because the {{DefaultRedirectStrategy}} only handles {{HEAD}} and {{GET}} 
requests.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

This seems to be a duplicate of MNG-6469. Please provide the full debug output, 
not just the snippet. I am aware of this issue, but have failed back then to 
properly reproduce this. 

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov commented on MNG-6785:
-

Try 3.6.3-SNAPSHOT first. Also provide debug logs of HttpClient.

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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=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] [Updated] (MNG-6785) Fail to deploy on Sonatype OSS since maven 3.5.4

2019-10-15 Thread Michael Osipov (Jira)


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

Michael Osipov updated MNG-6785:

Fix Version/s: waiting-for-feedback

> Fail to deploy on Sonatype OSS since maven 3.5.4
> 
>
> Key: MNG-6785
> URL: https://issues.apache.org/jira/browse/MNG-6785
> Project: Maven
>  Issue Type: Bug
>  Components: Deployment
>Affects Versions: 3.5.4, 3.6.2
> 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
> Fix For: waiting-for-feedback
>
>
> 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=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] [Comment Edited] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp

2019-10-11 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949296#comment-16949296
 ] 

Michael Osipov edited comment on MSHARED-837 at 10/11/19 9:05 AM:
--

As for the style: The ISO definition provides two styles basic and extended. 
Basic can drop {{-}} and {{:}} delimiters while extended retains them. All 
components date, time, offset but be either basic or extended format. You are 
not allowed to mix them. Just using {{X}} with the extended style would allow 
{{2019-10-11T10:56:00+02}} (valid), {{2019-10-11T10:56:00+0200}} (invalid) and 
{{2019-10-11T10:56:00+02}} (valid). In basic format this would be 
{{20191011T105600+02}} (valid), {{20191011T105600+0200}} (valid) and 
{{20191011T105600+02:00}} (invalid).
 This is due to the lenient and telescoping nature of SDF. See also 
[here|https://stackoverflow.com/q/13088140/696632]. So you can only use the 
extended format with this implementation and stick to {{XXX}} and all is fine.

I don't think that just changing code and updating test would have really 
helped because I wanted you to understand what I object here since you didn't 
understand how telescoping in SDF works. Principal understanding is more 
important than pure code. I will change my branch accordingly with the tests.


was (Author: michael-o):
As for the style: The ISO definition provides two styles basic and extended. 
Basic can drop {{-}} and {{::}} delimiters while extended retains them. All 
components date, time, offset but be either basic or extended format. You are 
not allowed to mix them. Just using {{X}} with the extended style would allow 
{{2019-10-11T10:56:00+02}} (valid), {{2019-10-11T10:56:00+0200}} (invalid) and 
{{2019-10-11T10:56:00+02}} (valid). In basic format this would be 
{{20191011T105600+02}} (valid), {{20191011T105600+0200}} (valid) and 
{{20191011T105600+02:00}} (invalid).
 This is due to the lenient and telescoping nature of SDF. See also 
[here|https://stackoverflow.com/q/13088140/696632]. So you can only use the 
extended format with this implementation and stick to {{XXX}} and all is fine.

 

I don't think that just changing code and updating test would have really 
helped because I wanted you just to understand what I object here since you 
didn't understand how telescoping in SDF works. Principal understanding is more 
important that pure code. I will change my branch accordingly with the tests.

> add an API to configure Reproducible Builds with outputTimestamp
> 
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure 
> archiver with an output timestamp: see 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because 
> Plexus Date injection uses local timezone, then is not reproducible: see 
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and 
> provide an API to parse this String to a Date, before calling 
> plexus-archiver's configureReproducible 
> https://github.com/codehaus-plexus/plexus-archiver/pull/121



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


[jira] [Commented] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp

2019-10-11 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16949296#comment-16949296
 ] 

Michael Osipov commented on MSHARED-837:


As for the style: The ISO definition provides two styles basic and extended. 
Basic can drop {{-}} and {{::}} delimiters while extended retains them. All 
components date, time, offset but be either basic or extended format. You are 
not allowed to mix them. Just using {{X}} with the extended style would allow 
{{2019-10-11T10:56:00+02}} (valid), {{2019-10-11T10:56:00+0200}} (invalid) and 
{{2019-10-11T10:56:00+02}} (valid). In basic format this would be 
{{20191011T105600+02}} (valid), {{20191011T105600+0200}} (valid) and 
{{20191011T105600+02:00}} (invalid).
 This is due to the lenient and telescoping nature of SDF. See also 
[here|https://stackoverflow.com/q/13088140/696632]. So you can only use the 
extended format with this implementation and stick to {{XXX}} and all is fine.

 

I don't think that just changing code and updating test would have really 
helped because I wanted you just to understand what I object here since you 
didn't understand how telescoping in SDF works. Principal understanding is more 
important that pure code. I will change my branch accordingly with the tests.

> add an API to configure Reproducible Builds with outputTimestamp
> 
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure 
> archiver with an output timestamp: see 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because 
> Plexus Date injection uses local timezone, then is not reproducible: see 
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and 
> provide an API to parse this String to a Date, before calling 
> plexus-archiver's configureReproducible 
> https://github.com/codehaus-plexus/plexus-archiver/pull/121



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


[jira] [Commented] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp

2019-10-10 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948326#comment-16948326
 ] 

Michael Osipov commented on MSHARED-837:


Both are intended to show you how it should be you can pick either one.

You obviously don't understand the difference between {{X}}, {{XX}}, {{XXX}}. 
{{X}} parses: 08, 0800, 08:00
{{XX}} parses: 08, 0800
{{XXX}} parses: 08:00

Since the datetime is in extended format, the tz offset has to be too. 
Therefore, it can only be {{XXX}}.

Even if you don't care, I *do* and you did ask for review. We are designing new 
things where we can use well-established formats/standards. I don't see reason 
to deviate from.

Just pick the first, modify the tests and you are done.

> add an API to configure Reproducible Builds with outputTimestamp
> 
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure 
> archiver with an output timestamp: see 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because 
> Plexus Date injection uses local timezone, then is not reproducible: see 
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and 
> provide an API to parse this String to a Date, before calling 
> plexus-archiver's configureReproducible 
> https://github.com/codehaus-plexus/plexus-archiver/pull/121



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


[jira] [Commented] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp

2019-10-09 Thread Michael Osipov (Jira)


[ 
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948004#comment-16948004
 ] 

Michael Osipov commented on MSHARED-837:


Ping!

> add an API to configure Reproducible Builds with outputTimestamp
> 
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
>  Issue Type: New Feature
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure 
> archiver with an output timestamp: see 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because 
> Plexus Date injection uses local timezone, then is not reproducible: see 
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and 
> provide an API to parse this String to a Date, before calling 
> plexus-archiver's configureReproducible 
> https://github.com/codehaus-plexus/plexus-archiver/pull/121



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


[jira] [Commented] (WAGON-567) Wagon should retry download on server side errors

2019-10-09 Thread Michael Osipov (Jira)


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

Michael Osipov commented on WAGON-567:
--

Please change the source links, I want to see what you ar referring to. the 
links are wrong.

> Wagon should retry download on server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|[https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L403]]
>  and [httpclient 
> source|[https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90]].
>  However, when the repo returns errors like 500 or 503, it does not. The 5xx 
> response from the repo might be a blip and maven should retry before giving 
> up.



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


[jira] [Updated] (WAGON-567) Wagon should retry download on server side errors

2019-10-09 Thread Michael Osipov (Jira)


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

Michael Osipov updated WAGON-567:
-
Fix Version/s: waiting-for-feedback

> Wagon should retry download on server side errors
> -
>
> Key: WAGON-567
> URL: https://issues.apache.org/jira/browse/WAGON-567
> Project: Maven Wagon
>  Issue Type: New Feature
>  Components: wagon-http
>Reporter: xueqian zhang
>Priority: Minor
> Fix For: waiting-for-feedback
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently wagon has a retry mechanism when there are connections issues with 
> repository manager like maven central, artifactory or nexus, see [wagon 
> source|[https://github.com/apache/maven-wagon/blob/dfd22586b6b934aa5a652ca32d57ed26067432fd/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L403]]
>  and [httpclient 
> source|[https://github.com/apache/httpcomponents-client/blob/4.5.x/httpclient/src/main/java/org/apache/http/impl/execchain/RetryExec.java#L90]].
>  However, when the repo returns errors like 500 or 503, it does not. The 5xx 
> response from the repo might be a blip and maven should retry before giving 
> up.



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


  1   2   3   4   5   6   7   8   9   10   >