[jira] [Commented] (DOXIATOOLS-64) Flaky test DocBookBookSinkTest
[ https://issues.apache.org/jira/browse/DOXIATOOLS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021875#comment-17021875 ] Michael Osipov commented on DOXIATOOLS-64: -- This is logically wrong. you cannot rely on the string representation for equality. On needs to compare on node level or have a canoincal string representation. > Flaky test DocBookBookSinkTest > -- > > Key: DOXIATOOLS-64 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-64 > Project: Maven Doxia Tools > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > Looks like the test assumes too much about attribute order > FAILURE! - in > org.apache.maven.doxia.book.services.renderer.docbook.DocBookBookSinkTest > testFigure(org.apache.maven.doxia.book.services.renderer.docbook.DocBookBookSinkTest) > Time elapsed: 0.008 sec <<< FAILURE! > junit.framework.ComparisonFailure: Wrong figure! > expected:<...ileref="figure.jpg" format="JPG...> but was:<...ormat="JPG" > fileref="figure.jpg...> > at junit.framework.Assert.assertEquals(Assert.java:81) > at > org.apache.maven.doxia.sink.AbstractSinkTest.testFigure(AbstractSinkTest.java:424) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-verifier-plugin] KroArtem commented on issue #2: [MVERIFIER-38] Define encoding for FileReader
KroArtem commented on issue #2: [MVERIFIER-38] Define encoding for FileReader URL: https://github.com/apache/maven-verifier-plugin/pull/2#issuecomment-577594477 @slachiewicz, ping again 😃 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-verifier-plugin] slachiewicz commented on issue #2: [MVERIFIER-38] Define encoding for FileReader
slachiewicz commented on issue #2: [MVERIFIER-38] Define encoding for FileReader URL: https://github.com/apache/maven-verifier-plugin/pull/2#issuecomment-577595394 Thx for reminder - please look for discussion on maven-dev mailing list 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-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021879#comment-17021879
]
Michael Osipov commented on WAGON-575:
--
Let me guess, you are using Java 11? You have been hit by
https://bugs.openjdk.java.net/browse/JDK-8235263. Please retry with Java 8 or
14 and report back.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Major
>
> 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 test:test:jar:1.0.0: Coul
[GitHub] [maven-verifier-plugin] michael-o commented on issue #2: [MVERIFIER-38] Define encoding for FileReader
michael-o commented on issue #2: [MVERIFIER-38] Define encoding for FileReader URL: https://github.com/apache/maven-verifier-plugin/pull/2#issuecomment-577597085 Why not use source encoding defined in the POM? 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-verifier-plugin] KroArtem commented on issue #2: [MVERIFIER-38] Define encoding for FileReader
KroArtem commented on issue #2: [MVERIFIER-38] Define encoding for FileReader URL: https://github.com/apache/maven-verifier-plugin/pull/2#issuecomment-577597199 @slachiewicz , there was no reaction except yours. As I have wrote in this PR, this plugin is used in two places and it is not clear how to replace it there. That's why I decided it's a good idea to fix these issues, release a new version and retire plugin. 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-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17021883#comment-17021883
]
Michael Medin commented on WAGON-575:
-
I went down that route myself and thats why I wanted to add a custom retry
handler.
But I do not think that is the case as the RetryHandler is never called at all
when the exception happens the constructor is called but never the retry
function.
The code for downloading the file happens (wagon copy stream) after the
handshake so I dot not see how it could retry regardless of what exception is
thrown from the underlying exception type.
But I will see if I can setup an early access build of java 14 and reproduce it
there.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Major
>
> 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.launch
[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&focusedCommentId=17021911#comment-17021911
]
Michael Osipov commented on WAGON-575:
--
That might be true, but I like to see the raw {{IOException}} and not the
wrapped one in Java 11.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Major
>
> 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 test:test:jar:1.0.0: Could not transfer
> artifact REDACTED from/to REDACTED (REDAC
[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-577630204 @eolivelli The master fails in Travis CI. It looks like the local repo contains old snapshot artifacts from another branch downloaded from the ASF Nexus. If it repo is not really deleted before the run, we would need to do it. Is it possible to delete the local repo in the script https://github.com/apache/maven-surefire/blob/master/.travis.yml ? 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] rosti-il commented on issue #318: [MNG-6853] - Don't box primitives where it's not needed
rosti-il commented on issue #318: [MNG-6853] - Don't box primitives where it's
not needed
URL: https://github.com/apache/maven/pull/318#issuecomment-577638662
@olamy This can only improve the performance because the `Integer.valueOf()`
calls to the `Integer.parseInt()` by itself. The `Integer.parseInt()` returns a
primitive while the `Integer.valueOf()` returns an object. Even when
`Integer.valueOf()` returns a cached object and doesn't create a new one it
executes the cache range check. Just take a look at the code of
`java.lang.Integer` in JDK8.
public static Integer valueOf(String s) throws NumberFormatException {
return Integer.valueOf(parseInt(s, 10));
}
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
public static int parseInt(String s) throws NumberFormatException {
return parseInt(s,10);
}
`valueOf()` and `parseLong()` of Long and Boolean are implemented by the
same way.
Also the code I propose to change uses primitives, so this change prevents
unnecessary unboxing, i.e. it can only improve the performance.
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-release] michael-o commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
michael-o commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations URL: https://github.com/apache/maven-release/pull/32#discussion_r370070779 ## File path: maven-release-api/src/main/java/org/apache/maven/shared/release/config/ReleaseDescriptor.java ## @@ -481,4 +481,12 @@ * @return String */ String getAutoResolveSnapshots(); + +/** + * Get whether the "--pin-externals" option in svn copy commands is enabled Review comment: use `@code` for the formatting. 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-release] michael-o commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
michael-o commented on a change in pull request #32: [MRELEASE-549] Add support
for the "--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#discussion_r370072056
##
File path:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java
##
@@ -168,6 +171,10 @@ public ReleaseResult simulate( ReleaseDescriptor
releaseDescriptor, ReleaseEnvir
logInfo( result, "Full run would be tagging remotely " +
basedirAlignedReleaseDescriptor.getScmSourceUrl()
+ " with label: '" + releaseDescriptor.getScmReleaseLabel() +
"'" );
}
+if ( releaseDescriptor.isPinExternals() )
+{
+logInfo( result, "Full run would pin externals" );
Review comment:
This should be consistent with the other log statement
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-release] michael-o commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
michael-o commented on a change in pull request #32: [MRELEASE-549] Add support
for the "--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#discussion_r370071275
##
File path:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmBranchPhase.java
##
@@ -143,6 +144,10 @@ public ReleaseResult simulate( ReleaseDescriptor
releaseDescriptor, ReleaseEnvir
logInfo( result, " To SCM URL: " +
releaseDescriptor.getScmBranchBase() );
}
logInfo( result, " with label: '" +
releaseDescriptor.getScmReleaseLabel() + "'" );
+if ( releaseDescriptor.isPinExternals() )
+{
+logInfo( result, " with pinned externals" );
Review comment:
with => and.
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-release] michael-o commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
michael-o commented on a change in pull request #32: [MRELEASE-549] Add support
for the "--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#discussion_r370071421
##
File path:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java
##
@@ -120,13 +120,16 @@ public ReleaseResult execute( ReleaseDescriptor
releaseDescriptor, ReleaseEnviro
new ScmTagParameters( releaseDescriptor.getScmCommentPrefix()
+ "copy for tag " + tagName );
scmTagParameters.setRemoteTagging(
releaseDescriptor.isRemoteTagging() );
scmTagParameters.setScmRevision(
releaseDescriptor.getScmReleasedPomRevision() );
+scmTagParameters.setPinExternals(
releaseDescriptor.isPinExternals() );
if ( getLogger().isDebugEnabled() )
{
getLogger().debug(
"ScmTagPhase :: scmTagParameters remotingTag " +
releaseDescriptor.isRemoteTagging() );
getLogger().debug(
"ScmTagPhase :: scmTagParameters scmRevision " +
releaseDescriptor.getScmReleasedPomRevision() );
getLogger().debug( "ScmTagPhase :: fileSet " + fileSet );
+getLogger().debug(
+"ScmTagPhase :: scmTagParameters pinExternals " +
releaseDescriptor.isPinExternals() );
Review comment:
Move this up to the other parameter logging.
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-release] michael-o commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
michael-o commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations URL: https://github.com/apache/maven-release/pull/32#discussion_r370070674 ## File path: maven-release-api/src/main/java/org/apache/maven/shared/release/config/ReleaseDescriptor.java ## @@ -481,4 +481,12 @@ * @return String */ String getAutoResolveSnapshots(); + +/** + * Get whether the "--pin-externals" option in svn copy commands is enabled Review comment: Get => Determines. 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] (DOXIATOOLS-54) LinkMatcher uses a singleton set
[ https://issues.apache.org/jira/browse/DOXIATOOLS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022031#comment-17022031 ] Elliotte Rusty Harold commented on DOXIATOOLS-54: - [https://github.com/apache/maven-doxia-linkcheck] is migrated so this can move forward > LinkMatcher uses a singleton set > > > Key: DOXIATOOLS-54 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-54 > Project: Maven Doxia Tools > Issue Type: Bug >Affects Versions: doxia-linkcheck-1.2 >Reporter: Daniel Wegener >Assignee: Elliotte Rusty Harold >Priority: Major > Labels: blocked > Attachments: DOXIATOOLS_54__Make_LinkMatcher_thread_safe_.patch > > > LinkMatcher.match() > (https://github.com/apache/maven-doxia-tools/blob/562f0e6c6cbca49190e97e6923910220f7be4be8/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/LinkMatcher.java#L54) > is not thread-safe and causes the maven-linkcheck-plugin to fail if used in > parallel builds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DOXIATOOLS-64) Flaky test DocBookBookSinkTest
[ https://issues.apache.org/jira/browse/DOXIATOOLS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022032#comment-17022032 ] Elliotte Rusty Harold commented on DOXIATOOLS-64: - Repo is migrated. This can move forward now. > Flaky test DocBookBookSinkTest > -- > > Key: DOXIATOOLS-64 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-64 > Project: Maven Doxia Tools > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Priority: Minor > > Looks like the test assumes too much about attribute order > FAILURE! - in > org.apache.maven.doxia.book.services.renderer.docbook.DocBookBookSinkTest > testFigure(org.apache.maven.doxia.book.services.renderer.docbook.DocBookBookSinkTest) > Time elapsed: 0.008 sec <<< FAILURE! > junit.framework.ComparisonFailure: Wrong figure! > expected:<...ileref="figure.jpg" format="JPG...> but was:<...ormat="JPG" > fileref="figure.jpg...> > at junit.framework.Assert.assertEquals(Assert.java:81) > at > org.apache.maven.doxia.sink.AbstractSinkTest.testFigure(AbstractSinkTest.java:424) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (DOXIATOOLS-64) Flaky test DocBookBookSinkTest
[ https://issues.apache.org/jira/browse/DOXIATOOLS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold reassigned DOXIATOOLS-64: --- Assignee: Elliotte Rusty Harold > Flaky test DocBookBookSinkTest > -- > > Key: DOXIATOOLS-64 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-64 > Project: Maven Doxia Tools > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > > Looks like the test assumes too much about attribute order > FAILURE! - in > org.apache.maven.doxia.book.services.renderer.docbook.DocBookBookSinkTest > testFigure(org.apache.maven.doxia.book.services.renderer.docbook.DocBookBookSinkTest) > Time elapsed: 0.008 sec <<< FAILURE! > junit.framework.ComparisonFailure: Wrong figure! > expected:<...ileref="figure.jpg" format="JPG...> but was:<...ormat="JPG" > fileref="figure.jpg...> > at junit.framework.Assert.assertEquals(Assert.java:81) > at > org.apache.maven.doxia.sink.AbstractSinkTest.testFigure(AbstractSinkTest.java:424) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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&focusedCommentId=17022082#comment-17022082
]
Michael Medin commented on WAGON-575:
-
Nothing seems changed in 2020-01-15 build of Java 14, will try with Java 8 as
well...
{{mvn clean install -X}}
{{Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)}}
{{Maven home: C:\java\apache-maven-3.6.3\bin\..}}
{{Java version: 14-ea, vendor: Oracle Corporation, runtime: C:\java\jdk-14}}
{{Default locale: sv_SE, platform encoding: Cp1252}}
{{OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"}}
{{...}}
{{[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 (REDACTED): GET request of: 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:564)}}
{{ 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.wagon.TransferFailedException: GET request of:
REDACTED from REDACTED failed}}
{{ at org.apache.maven.wagon.AbstractWagon.getTransfer
(AbstractWagon.java:412)}}
{{ at org.apache.maven.wagon.AbstractWagon.getTransfer
(AbstractWagon.java:338)}}
{{ at org.apache.maven.wagon.AbstractWagon.getTransfer
(AbstractWagon.java:307)}}
{{ at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:97)}}
{{ at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)}}
{{ 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
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
(BasicRepositoryConnector.java:644)}}
{{ at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:262)}}
{{ at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:499)}}
{{ at org.eclipse.aet
[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&focusedCommentId=17022094#comment-17022094
]
Michael Medin commented on WAGON-575:
-
Same thing with Java 8 (Exception is not wrapped but the issue remains):
{{mvn clean install -X}}
{{Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)}}
{{Maven home: C:\java\apache-maven-3.6.3\bin\..}}
{{Java version: 1.8.0_242, vendor: AdoptOpenJDK, runtime:
C:\java\jdk8u242-b08\jre}}
{{Default locale: sv_SE, platform encoding: Cp1252}}
{{OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"}}
{{...}}
{{Caused by: org.apache.maven.wagon.TransferFailedException: GET request of:
REDACTED from REDACTED failed}}
{{ at org.apache.maven.wagon.AbstractWagon.getTransfer
(AbstractWagon.java:412)}}
{{ at org.apache.maven.wagon.AbstractWagon.getTransfer
(AbstractWagon.java:338)}}
{{ at org.apache.maven.wagon.AbstractWagon.getTransfer
(AbstractWagon.java:307)}}
{{ at org.apache.maven.wagon.StreamWagon.getIfNewer (StreamWagon.java:97)}}
{{ at org.apache.maven.wagon.StreamWagon.get (StreamWagon.java:61)}}
{{ 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
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute
(BasicRepositoryConnector.java:644)}}
{{ at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:262)}}
{{ at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:499)}}
{{ at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:401)}}
{{ at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:229)}}
{{ at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
(DefaultRepositorySystem.java:340)}}
{{ at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:202)}}
{{ at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
(LifecycleDependencyResolver.java:243)}}
{{ 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 sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
{{ at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)}}
{{ at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)}}
{{ at java.lang.reflect.Method.invoke (Method.java:498)}}
{{ 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: java.net.SocketException: Connection reset}}
{{ at java.net.SocketInputStream.read (SocketInputStream.java:210)}}
{{ a
[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&focusedCommentId=17022096#comment-17022096
]
Michael Osipov commented on WAGON-575:
--
[~olegk], I assume that the old and the new {{HttpRequestRetryStrategy}} do
not qualify for in-flight retry?
[~MickeM], can you provide debug output of the HttpClient
(https://github.com/apache/maven/blob/master/maven-embedder/src/main/resources/META-INF/maven/slf4j-configuration.properties)
and the exact configuration you passed to Maven?
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Major
>
> 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.
[jira] [Commented] (SUREFIRE-1633) [JUnit5 follow-up #1343] JUnit Jupiter @Nested tests do not run when selecting enclosing class with Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022148#comment-17022148
]
Douglas Silva commented on SUREFIRE-1633:
-
Just put an '*' after name of outer class, on your case, something like this:
{{mvn -Dtest=com.mycompany.test.MyTest* surefire:test}}
> [JUnit5 follow-up #1343] JUnit Jupiter @Nested tests do not run when
> selecting enclosing class with Surefire
>
>
> Key: SUREFIRE-1633
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1633
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Reporter: Christian Stein
>Priority: Major
>
> https://github.com/junit-team/junit5/issues/1343
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1633) [JUnit5 follow-up #1343] JUnit Jupiter @Nested tests do not run when selecting enclosing class with Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022148#comment-17022148
]
Douglas Silva edited comment on SUREFIRE-1633 at 1/23/20 2:22 PM:
--
Just put an '*' after name of outer class, on your case, something like this:
{{mvn -Dtest=com.mycompany.test.MyTest* surefire:test}}
Let me know if this works...
was (Author: silramos):
Just put an '*' after name of outer class, on your case, something like this:
{{mvn -Dtest=com.mycompany.test.MyTest* surefire:test}}
> [JUnit5 follow-up #1343] JUnit Jupiter @Nested tests do not run when
> selecting enclosing class with Surefire
>
>
> Key: SUREFIRE-1633
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1633
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Reporter: Christian Stein
>Priority: Major
>
> https://github.com/junit-team/junit5/issues/1343
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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&focusedCommentId=17022154#comment-17022154
]
Michael Medin commented on WAGON-575:
-
This was without any particular config but I get the same result configuring a
retryhandler.
I will see if I can figure out how to enable logging and re-run this, but here
is some more details regarding my config, setup and tests...
pom file:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
test
test
1.0.0
jar
se.pricer.esl
delta
114.0.0-44634bb
provided
settings.xml
pricer
external:*
REDACTED
I get same results with:
{{mvn clean install -X -Dmaven.wagon.http.retryHandler.requestSentEnabled=true
-Dmaven.wagon.http.retryHandler.class=default
-Dmaven.wagon.http.retryHandler.count=5}}
and:
{{mvn clean install -X}}
Also writing a custom RetryHandler I get constructor but no call to
retryRequest:
{{mvn clean install -X -Dmaven.wagon.http.retryHandler.class=medin.name.Test}}
RetryHandler I use:
{{package medin.name;}}{{import java.io.IOException;}}
{{import
org.apache.maven.wagon.providers.http.httpclient.client.HttpRequestRetryHandler;}}
{{import
org.apache.maven.wagon.providers.http.httpclient.protocol.HttpContext;}}{{public
class Test implements HttpRequestRetryHandler {}}
{{ public Test() {}}
{{ System.out.println("->LOADING");}}
{{ System.out.println("->LOADING");}}
{{ System.out.println("->LOADING");}}
{{ System.out.println("->LOADING");}}
{{ System.out.println("->LOADING");}}
{{ System.out.println("->LOADING");}}
{{ System.out.println("->LOADING");}}
{{ }}}{{public boolean retryRequest(IOException e, int i, HttpContext
httpContext) {}}
{{ System.out.println("->");}}
{{ System.out.println("->");}}
{{ System.out.println("->");}}
{{ System.out.println("->");}}
{{ System.out.println("->");}}
{{ System.out.println("->" + e);}}
{{ System.out.println("->" + i);}}
{{ System.out.println("->" + httpContext);}}
{{ return false;}}
{{ }}}
{{}}}
Log:
{{...}}{{[DEBUG] stax:stax-api:jar:1.0.1:provided}}
{{->LOADING}}
{{->LOADING}}
{{->LOADING}}
{{->LOADING}}
{{->LOADING}}
{{->LOADING}}
{{->LOADING}}
{{[DEBUG] Using transporter WagonTransporter with priority -1.0 for REDACTED}}
{{[DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for
REDACTED}}
{{Downloading from REDACTED: REDACTED}}
{{[DEBUG] Writing tracking file REDACTED}}
{{[INFO]
}}
{{[INFO] BUILD FAILURE}}
{{[INFO]
}}
{{[INFO] Total time: 12.160 s}}
{{[INFO] Finished at: 2020-01-23T15:37:15+01:00}}
{{[INFO]
}}
{{[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: GET request of: 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: 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.
[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&focusedCommentId=17022158#comment-17022158
]
Oleg Kalnichevski commented on WAGON-575:
-
[~michael-o] HttpClient with default settings should automatically retry `safe`
requests upon an I/O error such as a connection reset. I am not quite sure why
it does not happen here.
Oleg
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Major
>
> 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 dependenc
[jira] [Created] (SUREFIRE-1747) spring-boot-maven-plugin with goal repackage make tests to silently not execute
Atle Tokle created SUREFIRE-1747:
Summary: spring-boot-maven-plugin with goal repackage make tests
to silently not execute
Key: SUREFIRE-1747
URL: https://issues.apache.org/jira/browse/SUREFIRE-1747
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 3.0.0-M4
Reporter: Atle Tokle
When integration-testing a spring boot application, and also having this plugin:
{code:xml}
org.springframework.boot
spring-boot-maven-plugin
repackage
{code}
the test is not executed by maven-failsafe-plugin. And no errors or warnings is
displayed to indicate that code is not tested.
When configuring phace like this they are executed
{code:xml}
org.springframework.boot
spring-boot-maven-plugin
post-integration-test
repackage
{code}
I found the answer here
https://stackoverflow.com/questions/50705270/mvn-spring-boot-plugin-breaks-integration-testing
But the build should either break or tests run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DOXIATOOLS-64) Flaky test DocBookBookSinkTest
[ https://issues.apache.org/jira/browse/DOXIATOOLS-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved DOXIATOOLS-64. - Resolution: Fixed > Flaky test DocBookBookSinkTest > -- > > Key: DOXIATOOLS-64 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-64 > Project: Maven Doxia Tools > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Looks like the test assumes too much about attribute order > FAILURE! - in > org.apache.maven.doxia.book.services.renderer.docbook.DocBookBookSinkTest > testFigure(org.apache.maven.doxia.book.services.renderer.docbook.DocBookBookSinkTest) > Time elapsed: 0.008 sec <<< FAILURE! > junit.framework.ComparisonFailure: Wrong figure! > expected:<...ileref="figure.jpg" format="JPG...> but was:<...ormat="JPG" > fileref="figure.jpg...> > at junit.framework.Assert.assertEquals(Assert.java:81) > at > org.apache.maven.doxia.sink.AbstractSinkTest.testFigure(AbstractSinkTest.java:424) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DOXIATOOLS-56) doxia-book-renderer has unit test errors
[ https://issues.apache.org/jira/browse/DOXIATOOLS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved DOXIATOOLS-56. - Resolution: Duplicate Duplicate of 64 which is now fixed > doxia-book-renderer has unit test errors > > > Key: DOXIATOOLS-56 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-56 > Project: Maven Doxia Tools > Issue Type: Bug > Components: Doxia Book Renderer >Affects Versions: doxia-book-renderer-1.2 >Reporter: Archimedes Trajano >Priority: Major > Labels: build > > When building the there is an error in one of the unit tests yielding > junit.framework.ComparisonFailure: Wrong figure! > expected:<...ileref="figure.jpg" format="JPG...> but was:<...ormat="JPG" > fileref="figure.jpg...> > Seen here > https://travis-ci.org/trajano/maven-doxia-tools/builds/211909987#L1513 > The error appears to be that the order of attributes is different, but since > it is XML it really should not matter and the unit test framework should > allow that. > However, the code is not compatible with the current version of Doxia and > stops working past version 1.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DOXIATOOLS-55) Drop httpclient
[ https://issues.apache.org/jira/browse/DOXIATOOLS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated DOXIATOOLS-55: Issue Type: Dependency upgrade (was: New Feature) > Drop httpclient > --- > > Key: DOXIATOOLS-55 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-55 > Project: Maven Doxia Tools > Issue Type: Dependency upgrade > Components: Doxia Linkcheck >Affects Versions: doxia-linkcheck-1.2 >Reporter: Archimedes Trajano >Priority: Major > > Rather than using HTTP Client just use the standard HttpUrlConnection which > will handle the current TLS protocols. Or switch to HttpComponents, I prefer > the HttpUrlConnection because it is standard. > Another option that is standard but a bit more difficult to set up is to use > JAX-RS > I have created a PR to address this > https://github.com/apache/maven-doxia-tools/pull/2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DOXIATOOLS-55) Drop httpclient
[ https://issues.apache.org/jira/browse/DOXIATOOLS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold resolved DOXIATOOLS-55. - Resolution: Not A Problem Based on the PR it looks like this isn't going to happen. > Drop httpclient > --- > > Key: DOXIATOOLS-55 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-55 > Project: Maven Doxia Tools > Issue Type: Dependency upgrade > Components: Doxia Linkcheck >Affects Versions: doxia-linkcheck-1.2 >Reporter: Archimedes Trajano >Priority: Major > > Rather than using HTTP Client just use the standard HttpUrlConnection which > will handle the current TLS protocols. Or switch to HttpComponents, I prefer > the HttpUrlConnection because it is standard. > Another option that is standard but a bit more difficult to set up is to use > JAX-RS > I have created a PR to address this > https://github.com/apache/maven-doxia-tools/pull/2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DOXIATOOLS-59) Link checker not handling anchors of fluido skin topbar very well
[
https://issues.apache.org/jira/browse/DOXIATOOLS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated DOXIATOOLS-59:
Issue Type: Bug (was: Improvement)
> Link checker not handling anchors of fluido skin topbar very well
> -
>
> Key: DOXIATOOLS-59
> URL: https://issues.apache.org/jira/browse/DOXIATOOLS-59
> Project: Maven Doxia Tools
> Issue Type: Bug
> Components: Doxia Linkcheck
>Affects Versions: doxia-linkcheck-1.2
>Reporter: Alix Lourme
>Priority: Minor
> Labels: up-for-grabs
> Attachments: bugfix.zip
>
>
> When you are using
> [maven-fluido-skin|https://maven.apache.org/skins/maven-fluido-skin/] with
> [topbar|https://maven.apache.org/skins/maven-fluido-skin/topbar/index.html],
> category menus are produced with a *single anchor* (*#*) like that:
> {code}
> Overview class="caret">
> {code}
> In this case, _maven-linkcheck-plugin_ fails. You can simply reproduce the
> problem with this _site.xml_:
> {code}
>
>
> org.apache.maven.skins
> maven-fluido-skin
> 1.7
>
>
>
> true
> false
>
>
>
>
> http://www.apache.org"; />
> https://maven.apache.org"; />
>
>
>
> {code}
>
> You can use *excludedLink* property, but the pattern to use in
> [LinkValidatorManager.matchPattern|https://github.com/apache/maven-doxia-linkcheck/blob/1afc9f52cecea900b0c21926973afc5460c7a12e/src/main/java/org/apache/maven/doxia/linkcheck/validation/LinkValidatorManager.java#L337]
> is a little tricky to found :
> * # : All links page are excluded
> * ^#$ : Not found ... Java pattern seems not really used
> * *# : Do the trick finally
> Snippet for proof:
> {code}
> String pattern = "#";
> System.out.println(matchPattern("#", pattern)); // --> true
> System.out.println(matchPattern("#localLink", pattern)); // --> true
> System.out.println(matchPattern("http://fake.url.org/index.html#";,
> pattern)); // --> true
>
> System.out.println(matchPattern("http://fake.url.org/index.html#link";,
> pattern)); // --> true
> pattern = "^#$";
> System.out.println(matchPattern("#", pattern)); // --> false
> System.out.println(matchPattern("#localLink", pattern)); // --> false
> System.out.println(matchPattern("http://fake.url.org/index.html#";,
> pattern)); // --> false
>
> System.out.println(matchPattern("http://fake.url.org/index.html#link";,
> pattern)); // --> false
> pattern = "*#";
> System.out.println(matchPattern("#", pattern)); // --> true
> System.out.println(matchPattern("#localLink", pattern)); // --> false
> System.out.println(matchPattern("http://fake.url.org/index.html#";,
> pattern)); // --> false ... corner case ?
>
> System.out.println(matchPattern("http://fake.url.org/index.html#link";,
> pattern)); // --> false
> {code}
>
> Perhaps consider a single anchor (#) as valid link by default could be useful
> and avoiding some headlock.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6848) Ci Friendly builds broke with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022259#comment-17022259
]
Jason Mathison commented on MNG-6848:
-
I was able to work on the merge to the point that it compiled, but tests
failed. And when I skipped tests to get it to build it completely fell apart
when I tried to use it to build one of our projects.
> Ci Friendly builds broke with 3.6.2
> ---
>
> Key: MNG-6848
> URL: https://issues.apache.org/jira/browse/MNG-6848
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Patrick Barry
>Priority: Major
>
> We currently use ci friendly versions introduced in 3.5.0
> [https://maven.apache.org/docs/3.5.0/release-notes.html] Using of CI friendly
> versions via ${revision}, ${sha1} and/or ${changelist} has been fixed
> MNG-6057, MNG-6090 and MNG-5895. It is very important to know if you are
> using the previously named properties for a version in your pom you have to
> use flatten-maven-plugin if you like to do an mvn install or mvn deploy more
> details can be found at Maven CI Friendly Versions.
>
> Our parent pom are defined with the following version attributes:
> {code:java}
> ${version}${revision}
> pom
> com.group
> my-proj
>
>0.0.1
>-SNAPSHOT
>
> {code}
> and then on our build machine, we mvn install -Drevision=
> our sub-modules inherit the version from parent like this:
> {code:java}
>
> com.group
> my-proj
>
> ${version}${revision}
> ..
>
> {code}
> This allows us to only have to define the version in one spot and all
> sub-modules will stay in sync with parent.
> This generated a warning but still worked until 3.6.2
> {noformat}
> 15:56:14 [WARNING] Some problems were encountered while building the
> effective model for com.group:little-proj:jar:2.0.0.48015:56:14 [WARNING]
> 'version' contains an expression but should be a constant. @
> com.group:my-proj:${version}${revision},
> /var/build/workspace/project/pom.xml, line 17, column 14{noformat}
> is now...
> {noformat}
> 15:54:12 [ERROR] 'dependencies.dependency.version' for
> com.group:little-proj:jar is missing. @
> com.group:test-proj:${version}${revision},
> /var/build/workspace/test/./test-proj/pom.xml, line 89, column 22{noformat}
> we use flatten plugin
> {code:java}
>
> org.codehaus.mojo
> flatten-maven-plugin
> 1.1.0
>
>
> flatten
> process-resources
>
> flatten
>
>
> true
> resolveCiFriendliesOnly
>
>
>
> flatten.clean
> clean
>
> clean
>
>
>
>
> true
> resolveCiFriendliesOnly
>
> {code}
> If this is not the proper way to use Ci-Friendly versions, what is?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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&focusedCommentId=17022262#comment-17022262
]
Michael Osipov commented on WAGON-575:
--
Let's wait for the debug logs.
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Major
>
> 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 test:test:jar:1.0.0: Could not transfer
> artifact REDACTED from/to REDACTED (REDACTED): GET request of: REDACTED from
> REDACTED failed}}
> {{ at org
[jira] [Commented] (MNG-6848) Ci Friendly builds broke with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022264#comment-17022264
]
Michael Osipov commented on MNG-6848:
-
[~Jason Mathison], can you strip down your project in such a way that we can
turn that an IT and add it to our suite? That would make reverting way easier.
> Ci Friendly builds broke with 3.6.2
> ---
>
> Key: MNG-6848
> URL: https://issues.apache.org/jira/browse/MNG-6848
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Patrick Barry
>Priority: Major
>
> We currently use ci friendly versions introduced in 3.5.0
> [https://maven.apache.org/docs/3.5.0/release-notes.html] Using of CI friendly
> versions via ${revision}, ${sha1} and/or ${changelist} has been fixed
> MNG-6057, MNG-6090 and MNG-5895. It is very important to know if you are
> using the previously named properties for a version in your pom you have to
> use flatten-maven-plugin if you like to do an mvn install or mvn deploy more
> details can be found at Maven CI Friendly Versions.
>
> Our parent pom are defined with the following version attributes:
> {code:java}
> ${version}${revision}
> pom
> com.group
> my-proj
>
>0.0.1
>-SNAPSHOT
>
> {code}
> and then on our build machine, we mvn install -Drevision=
> our sub-modules inherit the version from parent like this:
> {code:java}
>
> com.group
> my-proj
>
> ${version}${revision}
> ..
>
> {code}
> This allows us to only have to define the version in one spot and all
> sub-modules will stay in sync with parent.
> This generated a warning but still worked until 3.6.2
> {noformat}
> 15:56:14 [WARNING] Some problems were encountered while building the
> effective model for com.group:little-proj:jar:2.0.0.48015:56:14 [WARNING]
> 'version' contains an expression but should be a constant. @
> com.group:my-proj:${version}${revision},
> /var/build/workspace/project/pom.xml, line 17, column 14{noformat}
> is now...
> {noformat}
> 15:54:12 [ERROR] 'dependencies.dependency.version' for
> com.group:little-proj:jar is missing. @
> com.group:test-proj:${version}${revision},
> /var/build/workspace/test/./test-proj/pom.xml, line 89, column 22{noformat}
> we use flatten plugin
> {code:java}
>
> org.codehaus.mojo
> flatten-maven-plugin
> 1.1.0
>
>
> flatten
> process-resources
>
> flatten
>
>
> true
> resolveCiFriendliesOnly
>
>
>
> flatten.clean
> clean
>
> clean
>
>
>
>
> true
> resolveCiFriendliesOnly
>
> {code}
> If this is not the proper way to use Ci-Friendly versions, what is?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022445#comment-17022445
]
Tibor Digana commented on SUREFIRE-1745:
Try to use {{forkedProcessTimeoutInSeconds}} instead.
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIATOOLS-54) LinkMatcher uses a singleton set
[ https://issues.apache.org/jira/browse/DOXIATOOLS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022520#comment-17022520 ] Elliotte Rusty Harold commented on DOXIATOOLS-54: - This has now moved to https://github.com/apache/maven-doxia-linkcheck/blob/master/src/main/java/org/apache/maven/doxia/linkcheck/LinkCheck.java > LinkMatcher uses a singleton set > > > Key: DOXIATOOLS-54 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-54 > Project: Maven Doxia Tools > Issue Type: Bug >Affects Versions: doxia-linkcheck-1.2 >Reporter: Daniel Wegener >Assignee: Elliotte Rusty Harold >Priority: Major > Labels: blocked > Attachments: DOXIATOOLS_54__Make_LinkMatcher_thread_safe_.patch > > > LinkMatcher.match() > (https://github.com/apache/maven-doxia-tools/blob/562f0e6c6cbca49190e97e6923910220f7be4be8/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/LinkMatcher.java#L54) > is not thread-safe and causes the maven-linkcheck-plugin to fail if used in > parallel builds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] qerub commented on issue #262: Refer to correct property in skipping-tests doc
qerub commented on issue #262: Refer to correct property in skipping-tests doc URL: https://github.com/apache/maven-surefire/pull/262#issuecomment-577888150 I think we're mixing up three different issues here: 1. what the author of the current documentation had in mind when they wrote it. 2. the general state of the current documentation (that IMHO should describe current behavior even if it's bad). 3. the current behavior of the plugin (w.r.t. `skipTests`). This mini-PR only addresses point 1. Working on 2 doesn't seem valuable until 3 has been resolved. 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] [Comment Edited] (DOXIATOOLS-54) LinkMatcher uses a singleton set
[ https://issues.apache.org/jira/browse/DOXIATOOLS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022520#comment-17022520 ] Elliotte Rusty Harold edited comment on DOXIATOOLS-54 at 1/23/20 9:36 PM: -- This has now moved to https://github.com/apache/maven-doxia-linkcheck/blob/master/src/main/java/org/apache/maven/doxia/linkcheck/LinkMatcher.java was (Author: elharo): This has now moved to https://github.com/apache/maven-doxia-linkcheck/blob/master/src/main/java/org/apache/maven/doxia/linkcheck/LinkCheck.java > LinkMatcher uses a singleton set > > > Key: DOXIATOOLS-54 > URL: https://issues.apache.org/jira/browse/DOXIATOOLS-54 > Project: Maven Doxia Tools > Issue Type: Bug >Affects Versions: doxia-linkcheck-1.2 >Reporter: Daniel Wegener >Assignee: Elliotte Rusty Harold >Priority: Major > Labels: blocked > Attachments: DOXIATOOLS_54__Make_LinkMatcher_thread_safe_.patch > > > LinkMatcher.match() > (https://github.com/apache/maven-doxia-tools/blob/562f0e6c6cbca49190e97e6923910220f7be4be8/doxia-linkcheck/src/main/java/org/apache/maven/doxia/linkcheck/LinkMatcher.java#L54) > is not thread-safe and causes the maven-linkcheck-plugin to fail if used in > parallel builds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-doxia-linkcheck] elharo opened a new pull request #1: DOXIATOOLS-54: make LinkMatcher thread safe
elharo opened a new pull request #1: DOXIATOOLS-54: make LinkMatcher thread safe URL: https://github.com/apache/maven-doxia-linkcheck/pull/1 @michael-o This was a classic example of premature optimization. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (SUREFIRE-1747) spring-boot-maven-plugin with goal repackage make tests to silently not execute
[
https://issues.apache.org/jira/browse/SUREFIRE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1747.
--
Assignee: Tibor Digana
Resolution: Not A Problem
The problem is that you did not add {{maven-failsafe-plugin}} and run {{mvn
verify}}.
You have to read our Apache documentation for the Failsafe plugin. Read the
stackoverflow. It was written there!
> spring-boot-maven-plugin with goal repackage make tests to silently not
> execute
> ---
>
> Key: SUREFIRE-1747
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1747
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Atle Tokle
>Assignee: Tibor Digana
>Priority: Major
>
> When integration-testing a spring boot application, and also having this
> plugin:
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
>
> repackage
>
>
>
>
> {code}
> the test is not executed by maven-failsafe-plugin. And no errors or warnings
> is displayed to indicate that code is not tested.
> When configuring phace like this they are executed
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
> post-integration-test
>
> repackage
>
>
>
>
> {code}
> I found the answer here
> https://stackoverflow.com/questions/50705270/mvn-spring-boot-plugin-breaks-integration-testing
> But the build should either break or tests run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1633) [JUnit5 follow-up #1343] JUnit Jupiter @Nested tests do not run when selecting enclosing class with Surefire
[ https://issues.apache.org/jira/browse/SUREFIRE-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1633: --- Fix Version/s: Backlog > [JUnit5 follow-up #1343] JUnit Jupiter @Nested tests do not run when > selecting enclosing class with Surefire > > > Key: SUREFIRE-1633 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1633 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 5.x support >Reporter: Christian Stein >Priority: Major > Fix For: Backlog > > > https://github.com/junit-team/junit5/issues/1343 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1727) Failures during test template creation are ignored
[
https://issues.apache.org/jira/browse/SUREFIRE-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1727:
---
Fix Version/s: Backlog
> Failures during test template creation are ignored
> --
>
> Key: SUREFIRE-1727
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1727
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M4
>Reporter: Thomas Weißschuh
>Priority: Major
> Fix For: Backlog
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Junit5 allows dynamic creation of tests via {{ @TestTemplate }} and
> {{TestTemplateInvocationContextProvider}}.
> If the {{TestTemplateInvocationContextProvider}} fails with an exception
> itself or Junit itself rejects it then surefire still marks the test as
> successful.
> Both Intellij IDEA and the junit 5 console launcher mark the test method as
> failed.
> Examples:
> {code:java}
> package surefirebug;
> import java.util.stream.Stream;
> import org.junit.jupiter.api.extension.ExtensionContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContext;
> import org.junit.jupiter.api.extension.TestTemplateInvocationContextProvider;
> public class FailingTestTemplateInvocationContextProvider
> implements TestTemplateInvocationContextProvider {
> @Override
> public boolean supportsTestTemplate(ExtensionContext context) {
> return true;
> }
> @Override
> public Stream
> provideTestTemplateInvocationContexts(
> ExtensionContext context) {
> //throw new IllegalStateException(""); // throw a custom exception
> return Stream.of(); // this will be rejected by Junit itself with a
> PreconditionViolationException
> }
> }
> {code}
> {code:java}
> package surefirebug;
> import org.junit.jupiter.api.TestTemplate;
> import org.junit.jupiter.api.extension.ExtendWith;
> @ExtendWith(FailingTestTemplateInvocationContextProvider.class)
> class DemonstrationTest {
> @TestTemplate
> void testOne() {
> System.out.println("testOne");
> }
> }
> {code}
> Display in surefire:
> {noformat}
> ...
> [INFO] --- maven-surefire-plugin:3.0.0-M4:test (default-test) @ amps-utils ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running surefirebug.DemonstrationTest
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009
> s - in surefirebug.DemonstrationTest
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {noformat}
> Display in the console runner:
> {noformat}
> ╷
> ├─ JUnit Jupiter ✔
> │ └─ DemonstrationTest ✔
> │ └─ testOne() ✘ No supporting TestTemplateInvocationContextProvider
> provided an invocation context
> └─ JUnit Vintage ✔
> Failures (1):
> JUnit Jupiter:DemonstrationTest:testOne()
> MethodSource [className = 'surefirebug.DemonstrationTest', methodName =
> 'testOne', methodParameterTypes = '']
> => org.junit.platform.commons.PreconditionViolationException: No
> supporting TestTemplateInvocationContextProvider provided an invocation
> context
>
> org.junit.platform.commons.util.Preconditions.condition(Preconditions.java:296)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.validateWasAtLeastInvokedOnce(TestTemplateTestDescriptor.java:142)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:108)
>
> org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
>
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
>
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
>
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
>[...]
> Test run finished after 40 ms
> [ 4 containers found ]
> [ 0 containers skipped]
> [ 4 containers started]
> [ 0 containers aborted]
> [ 3 containers successful ]
> [
[jira] [Commented] (SUREFIRE-1747) spring-boot-maven-plugin with goal repackage make tests to silently not execute
[
https://issues.apache.org/jira/browse/SUREFIRE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022707#comment-17022707
]
Atle Tokle commented on SUREFIRE-1747:
--
[~tibordigana] That was not the problem. The maven-failsafe-plugin was added,
and I was running mvn verify.
And I did see in the output that maven-failsafe-plugin did start first doing
goal integration-test and then goal verify. But without running the test it
should run.
The one change to my project that fixed the problem was adding
post-integration-test to the spring-boot-maven-plugin.
> spring-boot-maven-plugin with goal repackage make tests to silently not
> execute
> ---
>
> Key: SUREFIRE-1747
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1747
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Atle Tokle
>Assignee: Tibor Digana
>Priority: Major
>
> When integration-testing a spring boot application, and also having this
> plugin:
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
>
> repackage
>
>
>
>
> {code}
> the test is not executed by maven-failsafe-plugin. And no errors or warnings
> is displayed to indicate that code is not tested.
> When configuring phace like this they are executed
> {code:xml}
>
> org.springframework.boot
> spring-boot-maven-plugin
>
>
> post-integration-test
>
> repackage
>
>
>
>
> {code}
> I found the answer here
> https://stackoverflow.com/questions/50705270/mvn-spring-boot-plugin-breaks-integration-testing
> But the build should either break or tests run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-release] theit commented on issue #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
theit commented on issue #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations URL: https://github.com/apache/maven-release/pull/32#issuecomment-578012895 @michael-o: I thought about a test, but honestly I don't know if that makes sense. This PR simply adds a boolean flag to the release descriptor and forwards it to the SCM implementation, i.e. maven-scm-plugin. 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-release] theit commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
theit commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations URL: https://github.com/apache/maven-release/pull/32#discussion_r370493806 ## File path: maven-release-api/src/main/java/org/apache/maven/shared/release/config/ReleaseDescriptor.java ## @@ -481,4 +481,12 @@ * @return String */ String getAutoResolveSnapshots(); + +/** + * Get whether the "--pin-externals" option in svn copy commands is enabled Review comment: Fixed. 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-release] theit commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
theit commented on a change in pull request #32: [MRELEASE-549] Add support for
the "--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#discussion_r370493887
##
File path:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmBranchPhase.java
##
@@ -143,6 +144,10 @@ public ReleaseResult simulate( ReleaseDescriptor
releaseDescriptor, ReleaseEnvir
logInfo( result, " To SCM URL: " +
releaseDescriptor.getScmBranchBase() );
}
logInfo( result, " with label: '" +
releaseDescriptor.getScmReleaseLabel() + "'" );
+if ( releaseDescriptor.isPinExternals() )
+{
+logInfo( result, " with pinned externals" );
Review comment:
Fixed.
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-release] theit commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
theit commented on a change in pull request #32: [MRELEASE-549] Add support for
the "--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#discussion_r370493950
##
File path:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java
##
@@ -120,13 +120,16 @@ public ReleaseResult execute( ReleaseDescriptor
releaseDescriptor, ReleaseEnviro
new ScmTagParameters( releaseDescriptor.getScmCommentPrefix()
+ "copy for tag " + tagName );
scmTagParameters.setRemoteTagging(
releaseDescriptor.isRemoteTagging() );
scmTagParameters.setScmRevision(
releaseDescriptor.getScmReleasedPomRevision() );
+scmTagParameters.setPinExternals(
releaseDescriptor.isPinExternals() );
if ( getLogger().isDebugEnabled() )
{
getLogger().debug(
"ScmTagPhase :: scmTagParameters remotingTag " +
releaseDescriptor.isRemoteTagging() );
getLogger().debug(
"ScmTagPhase :: scmTagParameters scmRevision " +
releaseDescriptor.getScmReleasedPomRevision() );
getLogger().debug( "ScmTagPhase :: fileSet " + fileSet );
+getLogger().debug(
+"ScmTagPhase :: scmTagParameters pinExternals " +
releaseDescriptor.isPinExternals() );
Review comment:
Fixed.
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-release] theit commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
theit commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations URL: https://github.com/apache/maven-release/pull/32#discussion_r370493856 ## File path: maven-release-api/src/main/java/org/apache/maven/shared/release/config/ReleaseDescriptor.java ## @@ -481,4 +481,12 @@ * @return String */ String getAutoResolveSnapshots(); + +/** + * Get whether the "--pin-externals" option in svn copy commands is enabled Review comment: Fixed. 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-release] theit commented on a change in pull request #32: [MRELEASE-549] Add support for the "--pin-externals" operations in SCM branch and tag operations
theit commented on a change in pull request #32: [MRELEASE-549] Add support for
the "--pin-externals" operations in SCM branch and tag operations
URL: https://github.com/apache/maven-release/pull/32#discussion_r370493975
##
File path:
maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/ScmTagPhase.java
##
@@ -168,6 +171,10 @@ public ReleaseResult simulate( ReleaseDescriptor
releaseDescriptor, ReleaseEnvir
logInfo( result, "Full run would be tagging remotely " +
basedirAlignedReleaseDescriptor.getScmSourceUrl()
+ " with label: '" + releaseDescriptor.getScmReleaseLabel() +
"'" );
}
+if ( releaseDescriptor.isPinExternals() )
+{
+logInfo( result, "Full run would pin externals" );
Review comment:
Fixed.
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] (SUREFIRE-1745) Global Junit Test timeout
[
https://issues.apache.org/jira/browse/SUREFIRE-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17022731#comment-17022731
]
Kishore Kumar commented on SUREFIRE-1745:
-
I tried forkedProcessTimeoutInSeconds (and
[forkedProcessExitTimeoutInSeconds|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkedProcessExitTimeoutInSeconds])
too, that is not helpful.
> Global Junit Test timeout
> -
>
> Key: SUREFIRE-1745
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1745
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M4
>Reporter: Kishore Kumar
>Priority: Major
>
> Hi,
> We need unit test level time-out similar to this
> [https://github.com/junit-team/junit4/wiki/Timeout-for-tests] in surefire
> where we can configure a timeout similar to
> _parallelTestsTimeoutForcedInSeconds_.
> Also, I've observed that _parallelTestsTimeoutForcedInSeconds_ is not able to
> stop the infinite loop kind of test, and for other kinds of test even after
> timeout error in the log, the test is marked as successful in the surefire
> report.
>
> Can we have something similar to Junit timeout in surefire where we can
> configure global test timeout which will only stop that particular test which
> takes more than configured time and mark it as timeout error in the report,
> without impacting/stopping any other test's execution?
> {code:java}
> @Test
> public void infiniteLoop(){
> while (true) {}
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
