[jira] [Comment Edited] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277726#comment-17277726
]
Igor Dvorzhak edited comment on WAGON-575 at 2/3/21, 6:31 AM:
--
[~michael-o] Yes, I think that 8u and 11u both are affected - this bug was
introduced in [JDK-8145252|https://bugs.openjdk.java.net/browse/JDK-8145252]
that added TLS v1.3 support in JDK 8 (after backport) and 11+
was (Author: medb):
[~michael-o] Yes, I think that 8u and 11u both are affected - this bug was
introduced in [JDK-8145252|https://bugs.openjdk.java.net/browse/JDK-8145252]
that added TLS v1.3 support in JDK 8 and 11+
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ 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:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke (Method.java:566)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)}}
> {{ at
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17277726#comment-17277726
]
Igor Dvorzhak commented on WAGON-575:
-
[~michael-o] Yes, I think that 8u and 11u both are affected - this bug was
introduced in [JDK-8145252|https://bugs.openjdk.java.net/browse/JDK-8145252]
that added TLS v1.3 support in JDK 8 and 11+
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ 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:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke (Method.java:566)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencies for project
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17269843#comment-17269843
]
Igor Dvorzhak commented on WAGON-575:
-
After looking closer in the root cause of this issues, I believe that it is
caused by [SSLSocketImpl erroneously wraps
SocketException|https://bugs.openjdk.java.net/browse/JDK-8214339] issue in
OpenJDK. While original issue affects OpenJDK 11 and was already [partially
fixed|https://bugs.openjdk.java.net/browse/JDK-8237578], it was [back-ported to
OpenJDK
8u272|https://github.com/AdoptOpenJDK/openjdk-jdk8u/commit/b03902ff772e9a1638054094a7140d95a6083f1d]
too.
This also confirmed by stack trace:
{code:java}
Failed to download
com/google/code/tempus-fugit/tempus-fugit/1.1/tempus-fugit-1.1.jar to
/home/bigtop/.m2/repository/com/google/code/tempus-fugit/tempus-fugit/1.1/tempus-fugit-1.1.jar.part
(attempt #1):
org.apache.maven.wagon.TransferFailedException: Transfer failed for
https://repo.maven.apache.org/maven2/com/google/code/tempus-fugit/tempus-fugit/1.1/tempus-fugit-1.1.jar
at
org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:1242)
at
org.apache.maven.wagon.providers.http.wagon.shared.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:1138)
at
org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:167)
at
org.apache.maven.wagon.StreamWagon.getIfNewerInternal(StreamWagon.java:129)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:96)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:63)
at
org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run(WagonTransporter.java:567)
at
org.eclipse.aether.transport.wagon.WagonTransporter.execute(WagonTransporter.java:435)
at
org.eclipse.aether.transport.wagon.WagonTransporter.get(WagonTransporter.java:412)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:457)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:364)
at
org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLException: Connection reset
at sun.security.ssl.Alert.createSSLException(Alert.java:127)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:324)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
at sun.security.ssl.TransportContext.fatal(TransportContext.java:262)
at
sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1303)
at sun.security.ssl.SSLSocketImpl.access$300(SSLSocketImpl.java:72)
at
sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:831)
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:186)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute(RetryExec.java:89)
at
[jira] [Comment Edited] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245321#comment-17245321
]
Igor Dvorzhak edited comment on WAGON-575 at 12/7/20, 4:19 PM:
---
I can add configuration if retry mechanism is acceptable in general.
It retries only `TransferFailedException` exceptions. I expect that wrong
credentials are covered by `AuthorizationException` exceptions that are not
retried.
I think that this PR does not need to deal with `InputStream` and progress
tracking because it retries whole file download e2e?
I agree that retries on a lower level will be a better and more efficient
solution, but from discussion in this thread I understood that nobody has a
time to implement them, so I proposed a quick fix that solves this problem.
was (Author: medb):
I can add configuration if retry mechanism is acceptable in general.
It retries only `TransferFailedException` exceptions. I expect that wrong
credentials are covered by `AuthorizationException` exceptions that are not
retried.
These PR is not dealing with `InputStream` and progress tracking because it
retries whole file download e2e.
I agree that retries on a lower level will be a better and more efficient
solution, but from discussion in this thread I understood that nobody has a
time to implement them, so I proposed a quick fix that solves this problem.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ 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
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245321#comment-17245321
]
Igor Dvorzhak commented on WAGON-575:
-
I can add configuration if retry mechanism is acceptable in general.
It retries only `TransferFailedException` exceptions. I expect that wrong
credentials are covered by `AuthorizationException` exceptions that are not
retried.
These PR is not dealing with `InputStream` and progress tracking because it
retries whole file download e2e.
I agree that retries on a lower level will be a better and more efficient
solution, but from discussion in this thread I understood that nobody has a
time to implement them, so I proposed a quick fix that solves this problem.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ 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:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke (Method.java:566)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)}}
> {{ at
[jira] [Comment Edited] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244923#comment-17244923
]
Igor Dvorzhak edited comment on WAGON-575 at 12/7/20, 3:22 AM:
---
I have sent a [PR|https://github.com/apache/maven-wagon/pull/75] that fixes
this issue by adding high-level retries for failed downloads in Maven Wagon.
It's less efficient retry mechanism than what was discussed in the comments
above but much simpler to implement and solves stability issue with my
multi-hour build.
Please, let me know if this is something that you are willing to consider/merge
with some additional work (configuration, tests, etc).
was (Author: medb):
I have sent a [PR|https://github.com/apache/maven-wagon/pull/75] that fixes
this issue by adding high-level retries for failed downloads in Maven Wagon.
It's less efficient retry mechanism than what was discussed in the comments
above but much simpler to implement and solves the issue for my build.
Please, let me know if this is something that you are willing to consider/merge
with some additional work (configuration, tests, etc).
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ 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:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
[jira] [Comment Edited] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244923#comment-17244923
]
Igor Dvorzhak edited comment on WAGON-575 at 12/7/20, 3:21 AM:
---
I have sent a [PR|https://github.com/apache/maven-wagon/pull/75] that fixes
this issue by adding high-level retries for failed downloads in Maven Wagon.
It's less efficient retry mechanism than what was discussed in the comments
above but much simpler to implement and solves the issue for my build.
Please, let me know if this is something that you are willing to consider/merge
with some additional work (configuration, tests, etc).
was (Author: medb):
I have sent a [PR|https://github.com/apache/maven-wagon/pull/75] that fixes
this issue by adding high-level retries for failed downloads. It's less
efficient retry mechanism than what was discussed in the comments above but
much simpler to implement and solves the issue for my build.
Please, let me know if this is something that you are willing to consider/merge
with some additional work (configuration, tests, etc).
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ 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:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at
[jira] [Commented] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244923#comment-17244923
]
Igor Dvorzhak commented on WAGON-575:
-
I have sent a [PR|https://github.com/apache/maven-wagon/pull/75] that fixes
this issue by adding high-level retries for failed downloads. It's less
efficient retry mechanism than what was discussed in the comments above but
much simpler to implement and solves the issue for my build.
Please, let me know if this is something that you are willing to consider/merge
with some additional work (configuration, tests, etc).
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ 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:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke (Method.java:566)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
>
[jira] [Commented] (MNG-714) When artifact not found on mirror the real site isn't checked
[ https://issues.apache.org/jira/browse/MNG-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16683001#comment-16683001 ] Igor Dvorzhak commented on MNG-714: --- Why this issue is closed? Was something done to address failover to mirrored repository if mirror not accessible or artifact is not present in mirror. Looks like this is a must have feature taking into account that "mirroring the entire central repository is not allowed": https://maven.apache.org/guides/mini/guide-mirror-settings.html > When artifact not found on mirror the real site isn't checked > - > > Key: MNG-714 > URL: https://issues.apache.org/jira/browse/MNG-714 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0-beta-1 >Reporter: Kenney Westerhof >Assignee: Jason van Zyl >Priority: Major > Attachments: MNG-714-maven-artifact-manager.patch > > Original Estimate: 3h > Remaining Estimate: 3h > > I'm using the settings.xml mirror feature as a local cache. Periodically I > upload my local repo > to the webserver specified as mirror. > When an artifact cannot be found on the mirror, the original site isn't > checked (and possibly the rest of the sites). > I'm not sure what the exact function of the mirror is (except caching?), but > repo1 is checked often regardless > of mirror presence, so I figure it's not meant to totally disable checking > the central repo's. > Simple reproduction: define a few mirrors in your settings.xml for central, > central-plugins and snapshots, pointing to > say file://tmp/empty/dir/. > Stacktrace: > [DEBUG] Error resolving artifact version from metadata. > org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate > resource in repository > at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343) > at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263) > at > org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93) > at > org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171) > at > org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96) > at > org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274) > at > org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156) > at > org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:229) >
[jira] [Comment Edited] (MSHADE-154) Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin)
[
https://issues.apache.org/jira/browse/MSHADE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438867#comment-16438867
]
Igor Dvorzhak edited comment on MSHADE-154 at 4/16/18 12:05 AM:
I found workaround, you need to package both main jar and jar with classifier
and then detach main jar from project after shading:
{code:xml}
maven-jar-plugin
classifier-jar
jar
${classifier}
maven-shade-plugin
. . .
org.codehaus.gmaven
gmaven-plugin
remove-primary-artifact
package
execute
project.getArtifact().setFile(null)
{code}
was (Author: medb):
I found workaround, you need to package both main jar and jar with classifier
and then detach main jar from project after shading:
{code:xml}
maven-jar-plugin
jar
classifier-jar
jar
${classifier}
maven-shade-plugin
. . .
org.codehaus.gmaven
gmaven-plugin
remove-primary-artifact
package
execute
project.getArtifact().setFile(null)
{code}
> Add ability for shade to find primary artifact from attached artifacts
> (similar to assembly-plugin)
> ---
>
> Key: MSHADE-154
> URL: https://issues.apache.org/jira/browse/MSHADE-154
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Affects Versions: 2.0
> Environment: all
>Reporter: Richard Sand
>Priority: Major
> Attachments: patch.txt, patch139and154.txt
>
>
> When switching from assembly-plugin to shade-plugin for a given project, I
> discovered that the shade plugin did not have the capability of using an
> attached artifact as the primary artifact - only the project's main artifact
> was supported.
> I've attached changes to add a configuration parameter
> "alternativeInputClassifier", which, when specified, tells the plugin to look
> for an artifact with the specified classifier in the project attachments, and
> to use that as the primary artifact. This makes shade behave similar to
> assembly-plugin, and allows shade to recognize attached artifacts generated
> by previous plugins in a maven execution.
> This was a trivial change, but required modifying several other classes and
> methods to accept the "primary" artifact as a parameter instead of a global
> variable. IMHO these changes are good for the plugin as a whole, as it will
> allow for future flexibility and logic for determining the entrypoint for the
> plugin (e.g. being able to run as a standalone goal with a specific artifact
> as input).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-154) Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin)
[
https://issues.apache.org/jira/browse/MSHADE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438867#comment-16438867
]
Igor Dvorzhak commented on MSHADE-154:
--
I found workaround, you need to package both main jar and jar with classifier
and then detach main jar from project after shading:
{code:xml}
maven-jar-plugin
jar
classifier-jar
jar
${classifier}
maven-shade-plugin
. . .
org.codehaus.gmaven
gmaven-plugin
remove-primary-artifact
package
execute
project.getArtifact().setFile(null)
{code}
> Add ability for shade to find primary artifact from attached artifacts
> (similar to assembly-plugin)
> ---
>
> Key: MSHADE-154
> URL: https://issues.apache.org/jira/browse/MSHADE-154
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Affects Versions: 2.0
> Environment: all
>Reporter: Richard Sand
>Priority: Major
> Attachments: patch.txt, patch139and154.txt
>
>
> When switching from assembly-plugin to shade-plugin for a given project, I
> discovered that the shade plugin did not have the capability of using an
> attached artifact as the primary artifact - only the project's main artifact
> was supported.
> I've attached changes to add a configuration parameter
> "alternativeInputClassifier", which, when specified, tells the plugin to look
> for an artifact with the specified classifier in the project attachments, and
> to use that as the primary artifact. This makes shade behave similar to
> assembly-plugin, and allows shade to recognize attached artifacts generated
> by previous plugins in a maven execution.
> This was a trivial change, but required modifying several other classes and
> methods to accept the "primary" artifact as a parameter instead of a global
> variable. IMHO these changes are good for the plugin as a whole, as it will
> allow for future flexibility and logic for determining the entrypoint for the
> plugin (e.g. being able to run as a standalone goal with a specific artifact
> as input).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-154) Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin)
[ https://issues.apache.org/jira/browse/MSHADE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438746#comment-16438746 ] Igor Dvorzhak commented on MSHADE-154: -- Hit this issue. Any plans to add this feature? > Add ability for shade to find primary artifact from attached artifacts > (similar to assembly-plugin) > --- > > Key: MSHADE-154 > URL: https://issues.apache.org/jira/browse/MSHADE-154 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 2.0 > Environment: all >Reporter: Richard Sand >Priority: Major > Attachments: patch.txt, patch139and154.txt > > > When switching from assembly-plugin to shade-plugin for a given project, I > discovered that the shade plugin did not have the capability of using an > attached artifact as the primary artifact - only the project's main artifact > was supported. > I've attached changes to add a configuration parameter > "alternativeInputClassifier", which, when specified, tells the plugin to look > for an artifact with the specified classifier in the project attachments, and > to use that as the primary artifact. This makes shade behave similar to > assembly-plugin, and allows shade to recognize attached artifacts generated > by previous plugins in a maven execution. > This was a trivial change, but required modifying several other classes and > methods to accept the "primary" artifact as a parameter instead of a global > variable. IMHO these changes are good for the plugin as a whole, as it will > allow for future flexibility and logic for determining the entrypoint for the > plugin (e.g. being able to run as a standalone goal with a specific artifact > as input). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
