[GitHub] [maven-surefire] Col-E commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Col-E commented on a change in pull request #249: Surefire-1701: Fix
@DisplayName breaking reruns
URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338352164
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java
##
@@ -187,12 +188,12 @@ private LauncherDiscoveryRequest
buildLauncherDiscoveryRequestForRerunFailures(
LauncherDiscoveryRequestBuilder builder = request().filters( filters
).configurationParameters(
configurationParameters );
// Iterate over recorded failures
-for ( TestIdentifier identifier : adapter.getFailures().keySet() )
+for ( TestIdentifier identifier : new HashSet<>(
adapter.getFailures().keySet() ) )
{
// Extract quantified test name data
String[] classMethodName = adapter.toClassMethodNameWithoutPlan(
identifier );
-String className = classMethodName[1];
-String methodName = classMethodName[3];
+String className = classMethodName[0];
Review comment:
I agree, but I do not think that is within the scope of this PR _(A simple
bug fix)_.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] Col-E commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Col-E commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338355808 ## File path: surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java ## @@ -865,6 +866,7 @@ void testAlwaysSkipped() throw new IllegalStateException( "this test should be never called" ); } +@org.junit.jupiter.api.DisplayName( "Fails twice" ) Review comment: > What if we coment the DisplayName? It will not rerun the tests as we found it in Jira? I'm not sure I follow. I've updated the test to print the failing test names if that's what you're looking for. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project
[
https://issues.apache.org/jira/browse/MNG-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Qian updated MNG-6793:
-
Description:
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.
was:
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.
> 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] [Created] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project
Daniel Qian created MNG-6793:
Summary: 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
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)
[GitHub] [maven-surefire] Col-E commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Col-E commented on a change in pull request #249: Surefire-1701: Fix
@DisplayName breaking reruns
URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338352164
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java
##
@@ -187,12 +188,12 @@ private LauncherDiscoveryRequest
buildLauncherDiscoveryRequestForRerunFailures(
LauncherDiscoveryRequestBuilder builder = request().filters( filters
).configurationParameters(
configurationParameters );
// Iterate over recorded failures
-for ( TestIdentifier identifier : adapter.getFailures().keySet() )
+for ( TestIdentifier identifier : new HashSet<>(
adapter.getFailures().keySet() ) )
{
// Extract quantified test name data
String[] classMethodName = adapter.toClassMethodNameWithoutPlan(
identifier );
-String className = classMethodName[1];
-String methodName = classMethodName[3];
+String className = classMethodName[0];
Review comment:
I agree, but I don't think that's within the scope of this PR _(A simple bug
fix)_.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] Col-E commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Col-E commented on a change in pull request #249: Surefire-1701: Fix
@DisplayName breaking reruns
URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338352164
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java
##
@@ -187,12 +188,12 @@ private LauncherDiscoveryRequest
buildLauncherDiscoveryRequestForRerunFailures(
LauncherDiscoveryRequestBuilder builder = request().filters( filters
).configurationParameters(
configurationParameters );
// Iterate over recorded failures
-for ( TestIdentifier identifier : adapter.getFailures().keySet() )
+for ( TestIdentifier identifier : new HashSet<>(
adapter.getFailures().keySet() ) )
{
// Extract quantified test name data
String[] classMethodName = adapter.toClassMethodNameWithoutPlan(
identifier );
-String className = classMethodName[1];
-String methodName = classMethodName[3];
+String className = classMethodName[0];
Review comment:
I agree, but I don't think that's within the scope of this issue _(A simple
bug fix)_.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] Col-E commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Col-E commented on a change in pull request #249: Surefire-1701: Fix
@DisplayName breaking reruns
URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338351993
##
File path:
surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java
##
@@ -843,7 +844,7 @@ void testPass()
void testAborted()
{
assumeFalse( true );
-throw new IllegalStateException( "this exception should neve
happen" );
+throw new IllegalStateException( "his exception should never
happen" );
Review comment:
Oops, don't know how that happened.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-resolver] Tibor17 edited a comment on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
Tibor17 edited a comment on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-545673852 The build is running [here](https://builds.apache.org/job/maven-box/job/maven-resolver/job/MRESOLVER-93/) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-resolver] Tibor17 commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
Tibor17 commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-545673852 The build is running [here|https://builds.apache.org/job/maven-box/job/maven-resolver/job/MRESOLVER-93/] This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] zymzxq commented on issue #57: WAGON-567: support retry on server side errors
zymzxq commented on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545671840 Note: in httpclient5 [DefaultServiceUnavailableRetryStrategy](https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/DefaultServiceUnavailableRetryStrategy.java#L84) respects retryAfter response header before falling back to default interval. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338315031 ## File path: surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java ## @@ -865,6 +866,7 @@ void testAlwaysSkipped() throw new IllegalStateException( "this test should be never called" ); } +@org.junit.jupiter.api.DisplayName( "Fails twice" ) Review comment: well, okay it cover the test scenario but since we made two changes (array indexes and added HashSet) we should assert the display names in the listener too. What if we coment the DisplayName? It will not rerun the tests as we found it in Jira? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Tibor17 commented on a change in pull request #249: Surefire-1701: Fix
@DisplayName breaking reruns
URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338313152
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java
##
@@ -187,12 +188,12 @@ private LauncherDiscoveryRequest
buildLauncherDiscoveryRequestForRerunFailures(
LauncherDiscoveryRequestBuilder builder = request().filters( filters
).configurationParameters(
configurationParameters );
// Iterate over recorded failures
-for ( TestIdentifier identifier : adapter.getFailures().keySet() )
+for ( TestIdentifier identifier : new HashSet<>(
adapter.getFailures().keySet() ) )
{
// Extract quantified test name data
String[] classMethodName = adapter.toClassMethodNameWithoutPlan(
identifier );
-String className = classMethodName[1];
-String methodName = classMethodName[3];
+String className = classMethodName[0];
Review comment:
It would be worth to use OOP and not string array because now I can see how
it is difficult to understand the indexes of the array and their meaning. So we
have a couple of class + method, and one group is the traditional and second is
named. So the class can have annotation as well.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Tibor17 commented on a change in pull request #249: Surefire-1701: Fix
@DisplayName breaking reruns
URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338313152
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java
##
@@ -187,12 +188,12 @@ private LauncherDiscoveryRequest
buildLauncherDiscoveryRequestForRerunFailures(
LauncherDiscoveryRequestBuilder builder = request().filters( filters
).configurationParameters(
configurationParameters );
// Iterate over recorded failures
-for ( TestIdentifier identifier : adapter.getFailures().keySet() )
+for ( TestIdentifier identifier : new HashSet<>(
adapter.getFailures().keySet() ) )
{
// Extract quantified test name data
String[] classMethodName = adapter.toClassMethodNameWithoutPlan(
identifier );
-String className = classMethodName[1];
-String methodName = classMethodName[3];
+String className = classMethodName[0];
Review comment:
It would be worth to use OOP and not string array because now I can see how
it is difficult to understand the indexes of the array and their meaning. So we
have a couple of clsaa and method, and one group is the traditional and second
is named. So the class can have annotation as well.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Tibor17 commented on a change in pull request #249: Surefire-1701: Fix
@DisplayName breaking reruns
URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338311566
##
File path:
surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java
##
@@ -843,7 +844,7 @@ void testPass()
void testAborted()
{
assumeFalse( true );
-throw new IllegalStateException( "this exception should neve
happen" );
+throw new IllegalStateException( "his exception should never
happen" );
Review comment:
why `his`?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases
[
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958277#comment-16958277
]
Stig Rohde Døssing commented on MNG-6759:
-
[~rfscholte] I forgot to add the new plugin to the parent project's module
list. It should be fixed now.
I'll take a look at adding a test and fix for the relocation functionality in
the next few days.
> [REGRESSION] Maven fails to use section from dependency when
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR] Try downloading the file manually from the project website.
> [ERROR]
> [ERROR] Then, install it using the command:
> [ERROR] mvn install:install-file -DgroupId=io.confluent
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar
> -Dfile=/path/to/file
> [ERROR]
> [ERROR] Alternatively, if you host your own repository you can deploy the
> file there:
> [ERROR] mvn deploy:deploy-file -DgroupId=io.confluent
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR] Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR] io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] apache.snapshots (https://repository.apache.org/snapshots,
> releases=false, snapshots=true),
> [ERROR] central (https://repo.maven.apache.org/maven2, releases=true,
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven
> 3.6.2 doesn't like?
> * Copying the section from ChildB into ChildA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases
[
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958169#comment-16958169
]
Robert Scholte commented on MNG-6759:
-
And Jenkins is not happy yet...
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6759/2/testReport/org.apache.maven.it/MavenITmng6759TransitiveDependencyRepositoriesTest/
I'll investigate.
> [REGRESSION] Maven fails to use section from dependency when
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR] Try downloading the file manually from the project website.
> [ERROR]
> [ERROR] Then, install it using the command:
> [ERROR] mvn install:install-file -DgroupId=io.confluent
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar
> -Dfile=/path/to/file
> [ERROR]
> [ERROR] Alternatively, if you host your own repository you can deploy the
> file there:
> [ERROR] mvn deploy:deploy-file -DgroupId=io.confluent
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR] Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR] io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] apache.snapshots (https://repository.apache.org/snapshots,
> releases=false, snapshots=true),
> [ERROR] central (https://repo.maven.apache.org/maven2, releases=true,
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven
> 3.6.2 doesn't like?
> * Copying the section from ChildB into ChildA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNGSITE-379) Unable to get example of Maven 3 lifecycle extension to work
[
https://issues.apache.org/jira/browse/MNGSITE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957981#comment-16957981
]
Herve Boutemy commented on MNGSITE-379:
---
moved the issue to MNGSITE
you probably could have a look at
https://maven.apache.org/studies/extension-demo/ and its sources: it's a
working demo when run with "mvn -Prun-its verify"
> Unable to get example of Maven 3 lifecycle extension to work
>
>
> Key: MNGSITE-379
> URL: https://issues.apache.org/jira/browse/MNGSITE-379
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Andreas Brieg
>Priority: Major
> Attachments: maven-extension-usage.zip, test-extension.zip
>
>
> I'm trying to create an extension for maven following the description on
> [https://maven.apache.org/examples/maven-3-lifecycle-extensions.html.]
> However I'm unable to get this to work. I have attached the extension I
> created based on the example description as [^test-extension.zip].
> After running {{mvn install}} on the extension and trying to use the
> extension in an example project like in [^maven-extension-usage.zip] the
> execution listener implemented in the extension is not loaded nor listening
> to any event.
> When looking in the artifact created for the extension I see that there is a
> generated {{META-INF/plexus/components.xml}} contained as expected.
> {code}
>
>
>
>
> org.apache.maven.execution.ExecutionListener
> default
> org.example.testextension.Foo
>
> false
>
>
>
> {code}
> Maven also tries to download the extension from the repo when building
> {{maven-extension-usage}}.
> Where is the error here and what should the example page for a maven
> extension better document?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Moved] (MNGSITE-379) Unable to get example of Maven 3 lifecycle extension to work
[
https://issues.apache.org/jira/browse/MNGSITE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy moved MNG-6792 to MNGSITE-379:
Component/s: (was: Plugins and Lifecycle)
(was: core)
(was: Bootstrap & Build)
Key: MNGSITE-379 (was: MNG-6792)
Affects Version/s: (was: 3.6.2)
Project: Maven Project Web Site (was: Maven)
> Unable to get example of Maven 3 lifecycle extension to work
>
>
> Key: MNGSITE-379
> URL: https://issues.apache.org/jira/browse/MNGSITE-379
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Andreas Brieg
>Priority: Major
> Attachments: maven-extension-usage.zip, test-extension.zip
>
>
> I'm trying to create an extension for maven following the description on
> [https://maven.apache.org/examples/maven-3-lifecycle-extensions.html.]
> However I'm unable to get this to work. I have attached the extension I
> created based on the example description as [^test-extension.zip].
> After running {{mvn install}} on the extension and trying to use the
> extension in an example project like in [^maven-extension-usage.zip] the
> execution listener implemented in the extension is not loaded nor listening
> to any event.
> When looking in the artifact created for the extension I see that there is a
> generated {{META-INF/plexus/components.xml}} contained as expected.
> {code}
>
>
>
>
> org.apache.maven.execution.ExecutionListener
> default
> org.example.testextension.Foo
>
> false
>
>
>
> {code}
> Maven also tries to download the extension from the repo when building
> {{maven-extension-usage}}.
> Where is the error here and what should the example page for a maven
> extension better document?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] suztomo commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
suztomo commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-545489001 @Tibor17 Checking in. Is there anything I can do to proceed to merge this? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6792) Unable to get example of Maven 3 lifecycle extension to work
[
https://issues.apache.org/jira/browse/MNG-6792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957872#comment-16957872
]
Andreas Brieg commented on MNG-6792:
I'm not sure which component applies for this ticket. Please correct me here.
> Unable to get example of Maven 3 lifecycle extension to work
>
>
> Key: MNG-6792
> URL: https://issues.apache.org/jira/browse/MNG-6792
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build, core, Plugins and Lifecycle
>Affects Versions: 3.6.2
>Reporter: Andreas Brieg
>Priority: Major
> Attachments: maven-extension-usage.zip, test-extension.zip
>
>
> I'm trying to create an extension for maven following the description on
> [https://maven.apache.org/examples/maven-3-lifecycle-extensions.html.]
> However I'm unable to get this to work. I have attached the extension I
> created based on the example description as [^test-extension.zip].
> After running {{mvn install}} on the extension and trying to use the
> extension in an example project like in [^maven-extension-usage.zip] the
> execution listener implemented in the extension is not loaded nor listening
> to any event.
> When looking in the artifact created for the extension I see that there is a
> generated {{META-INF/plexus/components.xml}} contained as expected.
> {code}
>
>
>
>
> org.apache.maven.execution.ExecutionListener
> default
> org.example.testextension.Foo
>
> false
>
>
>
> {code}
> Maven also tries to download the extension from the repo when building
> {{maven-extension-usage}}.
> Where is the error here and what should the example page for a maven
> extension better document?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6792) Unable to get example of Maven 3 lifecycle extension to work
Andreas Brieg created MNG-6792:
--
Summary: Unable to get example of Maven 3 lifecycle extension to
work
Key: MNG-6792
URL: https://issues.apache.org/jira/browse/MNG-6792
Project: Maven
Issue Type: Bug
Components: Bootstrap Build, core, Plugins and Lifecycle
Affects Versions: 3.6.2
Reporter: Andreas Brieg
Attachments: maven-extension-usage.zip, test-extension.zip
I'm trying to create an extension for maven following the description on
[https://maven.apache.org/examples/maven-3-lifecycle-extensions.html.] However
I'm unable to get this to work. I have attached the extension I created based
on the example description as [^test-extension.zip].
After running {{mvn install}} on the extension and trying to use the extension
in an example project like in [^maven-extension-usage.zip] the execution
listener implemented in the extension is not loaded nor listening to any event.
When looking in the artifact created for the extension I see that there is a
generated {{META-INF/plexus/components.xml}} contained as expected.
{code}
org.apache.maven.execution.ExecutionListener
default
org.example.testextension.Foo
false
{code}
Maven also tries to download the extension from the repo when building
{{maven-extension-usage}}.
Where is the error here and what should the example page for a maven extension
better document?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-wagon] michael-o commented on issue #57: WAGON-567: support retry on server side errors
michael-o commented on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545422350 @ok2c thank you for the evaluation. @ColinHebert Can you provide that PR? Would that be the backoff you want to introduce with the usage of HttpClient 5.0? I will go on the current approach with the `ServiceUnavailableRetryStrategy` for both client and server errors. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] michael-o closed pull request #55: Wagon-566
michael-o closed pull request #55: Wagon-566 URL: https://github.com/apache/maven-wagon/pull/55 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] michael-o edited a comment on issue #55: Wagon-566
michael-o edited a comment on issue #55: Wagon-566 URL: https://github.com/apache/maven-wagon/pull/55#issuecomment-545413786 Please follow the discussion on the JIRA ticket. This PR won't be merged. This is a server-side issue. What I will introduce is another Wagon property to normalize URIs. You decide whether this should be a System property or config property in `server.xml`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] michael-o commented on issue #55: Wagon-566
michael-o commented on issue #55: Wagon-566
URL: https://github.com/apache/maven-wagon/pull/55#issuecomment-545413786
Please follow the discussion on the JIRA ticket. This PR won't be merged.
This is a server-side issue. What I will introduce is another Wagon property to
normalize URIs. You decide whether this should be a System property or config
property in {{server.xml}}.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (WAGON-566) Fix for MSITE-738
[
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
[
https://issues.apache.org/jira/browse/WAGON-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957800#comment-16957800
]
Oleg Kalnichevski commented on WAGON-566:
-
[~michael-o] HttpClient by default normalizes consecutive "/" in the path
component only and drops the fragment component if present. If you want full
syntax normalization you should use {{ URI#normalize()}}.
Oleg
> 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
[
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] [Commented] (WAGON-566) Fix for MSITE-738
[
https://issues.apache.org/jira/browse/WAGON-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957764#comment-16957764
]
Oleg Kalnichevski commented on WAGON-566:
-
[~michael-o] For my point of view this is a server side issue. WAGON may
provide an option to normalize the URI but any reasonable web server should be
able to non-normalized URIs as well.
> 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)
[GitHub] [maven-wagon] ok2c commented on issue #57: WAGON-567: support retry on server side errors
ok2c commented on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545394826 > For 5.0 it seems trivial to add c as a parameter to getRetryInterval() (similar to retryRequest()) @ColinHebert I will happily review a PR for this change. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (WAGON-566) Fix for MSITE-738
[
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
[
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)
[GitHub] [maven-wagon] ColinHebert edited a comment on issue #57: WAGON-567: support retry on server side errors
ColinHebert edited a comment on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545361735 For 5.0 it seems trivial to add `c` as a parameter to `getRetryInterval()` (similar to `retryRequest()`). https://github.com/apache/httpcomponents-client/blob/07a9714f3b89509b231fddbb667eb79073e9872d/httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/ServiceUnavailableRetryExec.java#L94 https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/ServiceUnavailableRetryStrategy.java#L61 For 4.5.x and Wagon, I suppose that it leaves us with the original option which is deprecating backoff for the time being (and eventually reintroduce it when moving to HttpClient 5.x?), instead use the native support for protocol level retries. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] ColinHebert commented on issue #57: WAGON-567: support retry on server side errors
ColinHebert commented on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545361735 For 5.0 it seems trivial to add `c` as a parameter to `getRetryInterval()` (similar to `retryRequest()`). https://github.com/apache/httpcomponents-client/blob/07a9714f3b89509b231fddbb667eb79073e9872d/httpclient5/src/main/java/org/apache/hc/client5/http/impl/classic/ServiceUnavailableRetryExec.java#L94 For 4.5.x and Wagon, I suppose that it leaves us with the original option which is deprecating backoff for the time being (and eventually reintroduce it when moving to HttpClient 5.x?), instead use the native support for protocol level retries. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] ok2c commented on issue #57: WAGON-567: support retry on server side errors
ok2c commented on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545354682 > So if I understand @ok2c, there is no out-of-the-box way to do backoff on protocol level retries, as ServiceUnavailableRetryStrategy provides a retry interval which does not carry information on how many previous attempts have been made? @ColinHebert This is correct. There are two options here: * in 5.0 we can still extend or rework `ServiceUnavailableRetryStrategy` but one needs to hurry. * In 4.5.x one can replace `ServiceUnavailableRetryExec` with a custom request execution handler. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] ColinHebert commented on issue #57: WAGON-567: support retry on server side errors
ColinHebert commented on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545352286 So if I understand @ok2c, there is no out-of-the-box way to do backoff on protocol level retries, as `ServiceUnavailableRetryStrategy` provides a retry interval which does not carry information on how many previous attempts have been made? The only thing that could be reasonably done for a given request is adding jitter to the retry interval (which really isn't necessary). Is that correct? Also regarding the backoff strategies in wagon, that makes sense to me and lines up with my previous assumption "if we're retrying 3 times only by default, a backoff strategy feels unnecessarily complex to begin with". This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-wagon] ok2c commented on issue #57: WAGON-567: support retry on server side errors
ok2c commented on issue #57: WAGON-567: support retry on server side errors URL: https://github.com/apache/maven-wagon/pull/57#issuecomment-545349042 @michael-o @ColinHebert The original intent of `ConnectionBackoffStrategy` and `BackoffManager` was to dynamically reduce connection pool limits in case of the server overload. It should have no bearing on automatic request re-execution or recovery. Protocol level recovery logic should be handled by `ServiceUnavailableRetryStrategy` and transport level recovery logic should be handled by `HttpRequestRetryHandler`. I am not even sure if WAGON needs `ConnectionBackoffStrategy` and `BackoffManager` at all. Does this help in any way? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (WAGON-566) Fix for MSITE-738
[
https://issues.apache.org/jira/browse/WAGON-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957634#comment-16957634
]
Oleg Kalnichevski commented on WAGON-566:
-
[~michael-o] What HttpClient _must_ do is to ensure that absolute URIs can be
correctly split into their respective authority and path/query components. For
that end HttpClient must ensure there are no consecutive "/" in the path
component. HttpClient also normalizes location URIs in case of a redirect but
otherwise it makes no attempts to eliminate dot-segments in absolute URIs. I
suppose in this particular case may want to normalize request URIs to
disambiguate it (for various reasons) but fundamentally this is a server-side
concern in my opinion.
Oleg
> 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)
