[jira] [Commented] (MCOMPILER-452) release cannot be emptied to activate profiles compiling with previous Java version
[
https://issues.apache.org/jira/browse/MCOMPILER-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277754#comment-17277754
]
Lugan commented on MCOMPILER-452:
-
Thank you for you reply!
Yes I have seen that properties could not be removed, that's why I tried to
empty it.. but found this exception.
I thought that only replacing the line
{code}
if ( release != null )
{code}
by
{code}
if ( release != null && !release.isEmpty() )
{code}
would be interesting ?!
I workaround my problem by using profiles with and without the variable
declaration.
> release cannot be emptied to activate profiles compiling with previous Java
> version
> ---
>
> Key: MCOMPILER-452
> URL: https://issues.apache.org/jira/browse/MCOMPILER-452
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Lugan
>Priority: Minor
>
> I am working on a project where some sub modules maven are in compiled in
> Java 8, some other in Java 11.
> For modules where sources must be compiled in Java 8, we still want to write
> our tests in Java 11.
> I have defined 2 profiles :
> * Java 11 by default with the maven.compiler.release property set
> * Java 8 where the maven.compiler.release property is empty :
> {code:xml}
>
> 1.8
> 1.8
>
>
> {code}
> I have a IllegalArugmentException :
> {code:java}
> Caused by: java.lang.NumberFormatException: For input string: ""
> at java.lang.NumberFormatException.forInputString
> (NumberFormatException.java:65)
> at java.lang.Integer.parseInt (Integer.java:662)
> at java.lang.Integer.valueOf (Integer.java:983)
> at org.apache.maven.plugin.compiler.TestCompilerMojo.preparePaths
> (TestCompilerMojo.java:306)
> {code}
> After inspecting the plugin source code on github, I have found that release
> variable is tested to be null or not :
> {code:java}
> if ( release != null )
> {
> if ( Integer.valueOf( release ) < 9 )
> {
> {code}
> https://github.com/apache/maven-compiler-plugin/blob/master/src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java
> It would be more robust by checking if release is neither null nor empty.
--
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=17277726#comment-17277726
]
Igor Dvorzhak commented on WAGON-575:
-
[~michael-o] Yes, I think that 8u and 11u both are affected - this bug was
introduced in [JDK-8145252|https://bugs.openjdk.java.net/browse/JDK-8145252]
that added TLS v1.3 support in JDK 8 and 11+
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)}}
> {{ at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
> {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
> {{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke (Method.java:566)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)}}
> {{Caused by: org.apache.maven.project.DependencyResolutionException: Could
> not resolve dependencie
[jira] [Comment Edited] (WAGON-575) Retry for connection issues
[
https://issues.apache.org/jira/browse/WAGON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277726#comment-17277726
]
Igor Dvorzhak edited comment on WAGON-575 at 2/3/21, 6:31 AM:
--
[~michael-o] Yes, I think that 8u and 11u both are affected - this bug was
introduced in [JDK-8145252|https://bugs.openjdk.java.net/browse/JDK-8145252]
that added TLS v1.3 support in JDK 8 (after backport) and 11+
was (Author: medb):
[~michael-o] Yes, I think that 8u and 11u both are affected - this bug was
introduced in [JDK-8145252|https://bugs.openjdk.java.net/browse/JDK-8145252]
that added TLS v1.3 support in JDK 8 and 11+
> Retry for connection issues
> ---
>
> Key: WAGON-575
> URL: https://issues.apache.org/jira/browse/WAGON-575
> Project: Maven Wagon
> Issue Type: New Feature
> Components: wagon-http
>Affects Versions: 3.3.4
> Environment: windows and linux
>Reporter: Michael Medin
>Priority: Minor
>
> There are a RetryHandler and now also a ServiceRetryHandler but both seem to
> focus only the handshake and no the data stream.
> In our case we download large artifacts (1+Gb) over a sometimes shaky
> connection which causes frequent "Connection reset" issues.
> To mitigate this we started to implement retry logic based on this
> [https://maven.apache.org/wagon/wagon-providers/wagon-http/] document. But
> seems our retry handler is never invoked when the connection is reset.
> So after some digging into the source code it seems the retryhandler are only
> used when connecting to the server and once the connection has been
> established and the HTTP headers have been read there is no retry handling
> for the reminder stream copy.
> Looking at the code it seems non trivial to add retry for this at is split up
> so I wanted to know if I am missing something before looking at implementing
> a PR for this.
>
> A simple way to simulate this behavior is to start a maven build with some
> large dependencies and during the download phase just kill the internet
> connection.
> If you have a RetryHandler enabled it will never be called instead you will
> get a stack trace along the following:
> {{[ERROR] Failed to execute goal on project test: Could not resolve
> dependencies for project test:test:jar:1.0.0: Could not transfer artifact
> REDACTED from/to REDACTED from REDACTED failed: Connection reset -> [Help 1]}}
> {{org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project test: Could not resolve dependencies for project
> test:test:jar:1.0.0: Could not transfer artifact REDACTED from/to REDACTED
> (REDACTED): GET request of: REDACTED from REDACTED failed}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)}}
> {{ at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)}}
> {{ at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)}}
> {{ at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)}}
> {{ at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)}}
> {{ at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)}}
> {{ at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)}}
> {{ at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)}}
> {{ at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)}}
> {{ at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)}}
> {{ at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)}}
> {{ at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke (Method.java:566)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)}}
> {{ at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)}}
> {{
[jira] [Commented] (MINVOKER-263) integration test support for .kts pre/post hook scripts
[
https://issues.apache.org/jira/browse/MINVOKER-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277657#comment-17277657
]
Dariusz Kuc commented on MINVOKER-263:
--
While it would be great to support kts scripts I don't think it is feasible at
this moment. It looks like kts support is still fairly limited - basically it
can only be run from command line through _kotlinc_ compiler (as per
[https://kotlinlang.org/docs/tutorials/command-line.html#using-the-command-line-to-run-scripts]).
There is also undocumented [_script_ goal provided by
_kotlin-maven-plugin_|[https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-maven-plugin/src/main/java/org/jetbrains/kotlin/maven/ExecuteKotlinScriptMojo.java|https://github.com/JetBrains/kotlin/blob/master/libraries/tools/kotlin-maven-plugin/src/main/java/org/jetbrains/kotlin/maven/ExecuteKotlinScriptMojo.java)]]
that can be used to run arbitrary Kotlin scripts but it does so by invoking
the compiler as well.
> integration test support for .kts pre/post hook scripts
>
>
> Key: MINVOKER-263
> URL: https://issues.apache.org/jira/browse/MINVOKER-263
> Project: Maven Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 3.2.1
>Reporter: Dariusz Kuc
>Priority: Minor
>
> It would be great if {{maven-invoker-plugin}} could support Kotlin script
> files (.kts). This would allow to write maven-plugin completely in Kotlin
> without the need to fallback to Groovy/Java for integration tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #333: Add failOnFlakeCount option
Tibor17 commented on pull request #333: URL: https://github.com/apache/maven-surefire/pull/333#issuecomment-772155837 @oehme Do you have somewhere a backup of the initial IT test? @eolivelli I am glad of this code. WDYT, can we push it to master? 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
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #333: Add failOnFlakeCount option
Tibor17 commented on a change in pull request #333:
URL: https://github.com/apache/maven-surefire/pull/333#discussion_r569070727
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
Review comment:
>
>
> But why would the super class contain logic that only applies to a single
subclass?
Both plugins, Surefire and Failsafe, have 90% the same parameters. So they
always contained the method `verifyParameters()` in the super class. The
`VerifyMojo` is an exception and it has never had so many config params before.
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
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #333: Add failOnFlakeCount option
Tibor17 commented on a change in pull request #333:
URL: https://github.com/apache/maven-surefire/pull/333#discussion_r569071541
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireHelper.java
##
@@ -286,7 +289,15 @@ private static String createErrorMessage(
SurefireReportParameters reportParamet
}
else
{
-msg.append( "There are test failures.\n\nPlease refer to " )
+if ( result.getFailures() > 0 )
+{
+msg.append( "There are test failures." );
+}
+else
+{
+msg.append( "There are too many flakes." );
Review comment:
@oehme
Thx, a good job!
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
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #333: Add failOnFlakeCount option
Tibor17 commented on a change in pull request #333:
URL: https://github.com/apache/maven-surefire/pull/333#discussion_r569070727
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
Review comment:
>
>
> But why would the super class contain logic that only applies to a single
subclass?
Both plugins, Surefire and Failsafe, have 90% same parameters. So they
always contained the method `verifyParameters()` in the super class. The
`VerifyMojo` is an exception and it has never had so many config params.
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
[GitHub] [maven] michael-o closed pull request #426: [MNG-7068] - Manage Google Guava dependency independent
michael-o closed pull request #426: URL: https://github.com/apache/maven/pull/426 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
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #333: Add failOnFlakeCount option
Tibor17 commented on a change in pull request #333:
URL: https://github.com/apache/maven-surefire/pull/333#discussion_r568487013
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
+{
+if ( failOnFlakeCount < 0 )
Review comment:
@oehme
I am not talking about VerifyMojo, nothing but the SurefirePlugin class.
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
Review comment:
I am not talking about VerifyMojo, nothing but the SurefirePlugin class.
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
[GitHub] [maven] michael-o commented on pull request #426: [MNG-7068] - Manage Google Guava dependency independent
michael-o commented on pull request #426: URL: https://github.com/apache/maven/pull/426#issuecomment-771761284 Merged. 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
[GitHub] [maven-resolver] michael-o commented on pull request #88: [MRESOLVER-157] Drop ServiceLocator
michael-o commented on pull request #88: URL: https://github.com/apache/maven-resolver/pull/88#issuecomment-771733406 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
[GitHub] [maven-resolver] asfgit merged pull request #92: [MRESOLVER-160] Deprecate service locator
asfgit merged pull request #92: URL: https://github.com/apache/maven-resolver/pull/92 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
[GitHub] [maven] rfscholte commented on pull request #411: [MNG-7029] Remove super POM release profile
rfscholte commented on pull request #411: URL: https://github.com/apache/maven/pull/411#issuecomment-771662749 https://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#useReleaseProfile is already marked as deprecated 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
[GitHub] [maven] michael-o commented on pull request #440: Remove ServiceLocator and Service
michael-o commented on pull request #440: URL: https://github.com/apache/maven/pull/440#issuecomment-771755092 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
[GitHub] [maven] slachiewicz commented on pull request #421: Artifact.getPath() and .setPath()
slachiewicz commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-771985029 FYI: https://issues.apache.org/jira/browse/MNG-6444 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
[GitHub] [maven-resolver] asfgit closed pull request #91: [MRESOLVER-162] Restore binary compatibility
asfgit closed pull request #91: URL: https://github.com/apache/maven-resolver/pull/91 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
[GitHub] [maven-enforcer] slachiewicz merged pull request #89: [MENFORCER-379] - Update maven-common-artifact-filters to 3.1.1
slachiewicz merged pull request #89: URL: https://github.com/apache/maven-enforcer/pull/89 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
[GitHub] [maven] cstamas commented on pull request #440: Remove ServiceLocator and Service
cstamas commented on pull request #440: URL: https://github.com/apache/maven/pull/440#issuecomment-771897898 Looks good, and we did overlap a bit :) I pushed (not created PR) for "update for 1.70, minimal changes" and "update post 1.7.0, ie. 2.0.0 when we want to drop locator" https://github.com/apache/maven/compare/master...cstamas:for-170?expand=1 https://github.com/apache/maven/compare/master...cstamas:post-170?expand=1 For "post 1.7.0" IMO not only remove def ctor and init method, but injected things should be `final`... 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
[GitHub] [maven-resolver] cstamas commented on pull request #88: [MRESOLVER-157] Drop ServiceLocator
cstamas commented on pull request #88: URL: https://github.com/apache/maven-resolver/pull/88#issuecomment-771830039 LGTM, thanks. As per comment on MRESOLVER-157, I think this should NOT be merged until 1.7.0 is out (as on master.`ServiceLocator` is already deprecated). 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
[GitHub] [maven] asfgit closed pull request #411: [MNG-7029] Remove super POM release profile
asfgit closed pull request #411: URL: https://github.com/apache/maven/pull/411 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
[GitHub] [maven-invoker] slachiewicz commented on pull request #6: MSHARED-978 add 'quiet' flag
slachiewicz commented on pull request #6: URL: https://github.com/apache/maven-invoker/pull/6#issuecomment-771953558 Thank you - merged - will be part of the upcoming 3.1.0 release. 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
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#discussion_r568863257 ## File path: maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/NoLockSyncContextFactory.java ## @@ -22,39 +22,42 @@ import java.util.Collection; import javax.inject.Named; +import javax.inject.Singleton; import org.eclipse.aether.RepositorySystemSession; import org.eclipse.aether.SyncContext; import org.eclipse.aether.artifact.Artifact; -import org.eclipse.aether.spi.synccontext.SyncContextFactory; import org.eclipse.aether.metadata.Metadata; /** * A factory to create synchronization contexts. This default implementation does not provide any real * synchronization but merely completes the repository system. */ -@Named -public class DefaultSyncContextFactory -implements SyncContextFactory, org.eclipse.aether.impl.SyncContextFactory +@Singleton +@Named( NoLockSyncContextFactory.NAME ) +public class NoLockSyncContextFactory Review comment: Frankly, I'd drop this class, as current master (and 1.6.x as for that matter) suffers from MRESOVER-153, so this class is really an implementation "we know to cause problems". 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
[GitHub] [maven-integration-testing] asfgit merged pull request #86: [MNG-7029] Remove super POM release profile
asfgit merged pull request #86: URL: https://github.com/apache/maven-integration-testing/pull/86 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
[GitHub] [maven-resolver] cstamas edited a comment on pull request #91: [MRESOLVER-162] Restore binary compatibility
cstamas edited a comment on pull request #91: URL: https://github.com/apache/maven-resolver/pull/91#issuecomment-771531006 Try to run them... if you look at demo snippets, they are built but not run by maven build, those are "demo" code that all have `static void main`, so I just ran them from my IDE, and they all failed with CNFEx (as they pull maven-resolver-provider from maven) as thry look for ServiceLocator in "old" place, but failing to find it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] oehme commented on a change in pull request #333: Add failOnFlakeCount option
oehme commented on a change in pull request #333:
URL: https://github.com/apache/maven-surefire/pull/333#discussion_r568468631
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
Review comment:
SurefirePlugin and VerifyMojo do not have a common base class.
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
+{
+if ( failOnFlakeCount < 0 )
Review comment:
See above, this wouldn't make sense because IntegrationTestMojo does not
have `failOnFlakeCount`. That's in the VerifyMojo, which doesn't have the same
base class.
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireHelper.java
##
@@ -286,7 +289,15 @@ private static String createErrorMessage(
SurefireReportParameters reportParamet
}
else
{
-msg.append( "There are test failures.\n\nPlease refer to " )
+if ( result.getFailures() > 0 )
+{
+msg.append( "There are test failures." );
+}
+else
+{
+msg.append( "There are too many flakes." );
Review comment:
Done, both messages are reported now if both conditions are true. Also,
the number of flakes and failOnFlakeCount are reported now.
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
Review comment:
But why would the super class contain logic that only applies to a
single subclass?
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
Review comment:
Nevermind, I see the if-else in that method now.
##
File path:
maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java
##
@@ -880,4 +900,20 @@ protected final ForkNodeFactory getForkNode()
{
return forkNode;
}
+
+@Override
+boolean verifyParameters() throws MojoFailureException,
MojoExecutionException
Review comment:
Nevermind, I see the if-else in that method now. Moved call up to the
base class.
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
[GitHub] [maven] michael-o edited a comment on pull request #177: [MNG-6471] during parallel build, ensure to set the thread name to the artifactId
michael-o edited a comment on pull request #177: URL: https://github.com/apache/maven/pull/177#issuecomment-771887901 @rmannibucau I have picked up and rebased your commit, also added more context because the sole module name can occur multiple times in a large reactor. If no one objects I will merge this in a week or so: 1c599ec173d145b76345f5f3a9fd36204b69aba2 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
[GitHub] [maven-invoker] asfgit closed pull request #6: MSHARED-978 add 'quiet' flag
asfgit closed pull request #6: URL: https://github.com/apache/maven-invoker/pull/6 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
[GitHub] [maven] michael-o commented on pull request #177: [MNG-6471] during parallel build, ensure to set the thread name to the artifactId
michael-o commented on pull request #177: URL: https://github.com/apache/maven/pull/177#issuecomment-771887901 @rmannibucau I have picked up and rebased your commit, also added more context because the sole module name can occur multiple times in a large reactor. If no one objects I will merge this in a week or so. 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
[GitHub] [maven-resolver] asfgit closed pull request #86: [MRESOLVER-156] Manage Google Guava dependency independent
asfgit closed pull request #86: URL: https://github.com/apache/maven-resolver/pull/86 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
[GitHub] [maven-resolver] michael-o commented on pull request #91: [MRESOLVER-162] Restore binary compatibility
michael-o commented on pull request #91: URL: https://github.com/apache/maven-resolver/pull/91#issuecomment-771553441 Btw, when you try to compile Maven with Resolver master it does not work either. 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
[GitHub] [maven-shade-plugin] gnodet commented on pull request #16: [MSHADE-148] Don't attach exclusions that are already present
gnodet commented on pull request #16: URL: https://github.com/apache/maven-shade-plugin/pull/16#issuecomment-771810447 I also have this issue when building Apache Camel with a parallel build, similar to the above example. Given this looks like a threading issue, it's not always reproducible, so it's quite hard to think about a test which could reliably exercise the problem. 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
[GitHub] [maven-resolver] cstamas commented on pull request #91: [MRESOLVER-162] Restore binary compatibility
cstamas commented on pull request #91: URL: https://github.com/apache/maven-resolver/pull/91#issuecomment-771531006 Try to run them... if you look at demo snippets, they are built but not run by maven build, those are "demo" code that all have `static void main`, so I just ran them from my IDE, and they all failed with CNFEx (as they pull maven-resolver-provider from maven) for ServiceLocator in "old" place, but failing to find it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on a change in pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#discussion_r568875978 ## File path: maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/NoLockSyncContextFactory.java ## @@ -22,39 +22,42 @@ import java.util.Collection; import javax.inject.Named; +import javax.inject.Singleton; import org.eclipse.aether.RepositorySystemSession; import org.eclipse.aether.SyncContext; import org.eclipse.aether.artifact.Artifact; -import org.eclipse.aether.spi.synccontext.SyncContextFactory; import org.eclipse.aether.metadata.Metadata; /** * A factory to create synchronization contexts. This default implementation does not provide any real * synchronization but merely completes the repository system. */ -@Named -public class DefaultSyncContextFactory -implements SyncContextFactory, org.eclipse.aether.impl.SyncContextFactory +@Singleton +@Named( NoLockSyncContextFactory.NAME ) +public class NoLockSyncContextFactory Review comment: That is absolutely correct, but shouldn't it remain for testing purposes and proof that real code works? ## File path: maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/NoLockSyncContextFactory.java ## @@ -22,39 +22,42 @@ import java.util.Collection; import javax.inject.Named; +import javax.inject.Singleton; import org.eclipse.aether.RepositorySystemSession; import org.eclipse.aether.SyncContext; import org.eclipse.aether.artifact.Artifact; -import org.eclipse.aether.spi.synccontext.SyncContextFactory; import org.eclipse.aether.metadata.Metadata; /** * A factory to create synchronization contexts. This default implementation does not provide any real * synchronization but merely completes the repository system. */ -@Named -public class DefaultSyncContextFactory -implements SyncContextFactory, org.eclipse.aether.impl.SyncContextFactory +@Singleton +@Named( NoLockSyncContextFactory.NAME ) +public class NoLockSyncContextFactory Review comment: If you really want to drop, just do, but I think it has its usecases. 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
[GitHub] [maven] michael-o commented on pull request #411: [MNG-7029] Remove super POM release profile
michael-o commented on pull request #411: URL: https://github.com/apache/maven/pull/411#issuecomment-771476292 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
[GitHub] [maven] MartinKanters merged pull request #429: [MNG-7051] - Optionally skip non-existing profiles and break on missing required profiles
MartinKanters merged pull request #429: URL: https://github.com/apache/maven/pull/429 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
[GitHub] [maven-common-artifact-filters] asfgit closed pull request #15: Big speed improvements for patterns that do not contain any wildcard
asfgit closed pull request #15: URL: https://github.com/apache/maven-common-artifact-filters/pull/15 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
[GitHub] [maven-integration-testing] MartinKanters merged pull request #87: [MNG-7051] Test activation of non-existing profiles
MartinKanters merged pull request #87: URL: https://github.com/apache/maven-integration-testing/pull/87 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
[jira] [Commented] (MINVOKER-182) Different groovy versions on test classpath can cause ClassCastException
[
https://issues.apache.org/jira/browse/MINVOKER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277497#comment-17277497
]
Bertrand Martin commented on MINVOKER-182:
--
Suggestion: Use [groovysh|https://groovy-lang.org/groovysh.html] to run
*verify.groovy*, so there is no conflict with the current JVM and whatever
dependencies are loaded by the project being tested with maven-invoker-plugin.
> Different groovy versions on test classpath can cause ClassCastException
>
>
> Key: MINVOKER-182
> URL: https://issues.apache.org/jira/browse/MINVOKER-182
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Andrew Schurman
>Priority: Minor
>
> When {{addTestClassPath}} is set and you have a different version of groovy
> than invoker on your classpath, you will run into {{ClassCastException}} when
> pre-/post- build hooks are run for tests. This occurs due to invoker creating
> groovy scripts in its version of groovy, but using a different version of
> groovy as the runtime (since test classpath elements are loaded first when
> {{addTestClassPath=true}}).
> In my specific case, I had a transitive dependency on groovy 1.7, but invoker
> uses groovy 2.0. Being transitive does make it harder to spot, but
> more importantly you may not have access to the dependency that depends on
> groovy. This could make swapping groovy versions impossible depending on the
> gap between versions.
> Stack trace:
> {code}
> groovy.lang.GroovyRuntimeException: Failed to create Script instance for
> class: class Script1. Reason: java.lang.ClassCastException: Script1 cannot be
> cast to groovy.lang.GroovyObject
> at
> org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:443)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:625)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:516)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:556)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:527)
> at
> org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:83)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:249)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:177)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1692)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1360)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:1210)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:723)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException
[jira] [Commented] (MINVOKER-274) Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal reflection
[
https://issues.apache.org/jira/browse/MINVOKER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277496#comment-17277496
]
Bertrand Martin commented on MINVOKER-274:
--
Suggestion: Use [groovysh|https://groovy-lang.org/groovysh.html] to run
*verify.groovy*, so there is no conflict with the current JVM and whatever
dependencies are loaded by the project being tested with maven-invoker-plugin.
> Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal
> reflection
> ---
>
> Key: MINVOKER-274
> URL: https://issues.apache.org/jira/browse/MINVOKER-274
> Project: Maven Invoker Plugin
> Issue Type: Improvement
> Environment: JDK9+
>Reporter: Bertrand Martin
>Priority: Major
> Labels: Java8
>
> h1. Problem
> Running integration tests with *maven-invoker-plugin* in JDK with version >=
> 9 (incl. OpenJDK 11, 14, 15, etc.) will generate these un-aesthetic messages:
> {noformat}
> [INFO] run post-build script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/d:/Dev2/maven/repository/org/codehaus/groovy/groovy-all/2.4.8/groovy-all-2.4.8.jar)
> to method java.lang.Object.clone()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> h1. Specification
> Use Groovy 3.x which solved all illegal accesses that were in 2.x.
> Most current version is:
> {code:xml}
> org.codehaus.groovy
> groovy-all
> 3.0.7
> pom
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MINVOKER-261) Confusing error message
[
https://issues.apache.org/jira/browse/MINVOKER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277482#comment-17277482
]
Sylwester Lachiewicz commented on MINVOKER-261:
---
This message is from maven-invoker lib:
[https://github.com/apache/maven-invoker/blob/maven-invoker-3.0.1/src/main/java/org/apache/maven/shared/invoker/MavenCommandLineBuilder.java#L541]
> Confusing error message
> ---
>
> Key: MINVOKER-261
> URL: https://issues.apache.org/jira/browse/MINVOKER-261
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Minor
> Fix For: 3.2.2
>
>
> It took me a while to figure this one out:
> java.lang.IllegalStateException: ${maven.home} is not specified as a
> directory: '/Cellar/maven/3.6.0/bin'.
>
> Better message:
> ${maven.home} is set to '/Cellar/maven/3.6.0/bin' which does not exist
> or perhaps
> ${maven.home} is set to '/Cellar/maven/3.6.0/bin' which is not a directory
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MINVOKER-261) Confusing error message
[
https://issues.apache.org/jira/browse/MINVOKER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MINVOKER-261:
--
Fix Version/s: 3.2.2
> Confusing error message
> ---
>
> Key: MINVOKER-261
> URL: https://issues.apache.org/jira/browse/MINVOKER-261
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Minor
> Fix For: 3.2.2
>
>
> It took me a while to figure this one out:
> java.lang.IllegalStateException: ${maven.home} is not specified as a
> directory: '/Cellar/maven/3.6.0/bin'.
>
> Better message:
> ${maven.home} is set to '/Cellar/maven/3.6.0/bin' which does not exist
> or perhaps
> ${maven.home} is set to '/Cellar/maven/3.6.0/bin' which is not a directory
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MINVOKER-263) integration test support for .kts pre/post hook scripts
[
https://issues.apache.org/jira/browse/MINVOKER-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277481#comment-17277481
]
Sylwester Lachiewicz commented on MINVOKER-263:
---
Any hint on how to start working on Kotlin support?
To start I need something more like - how to run Kotlin file from Java (Maven
sample preferred). Or even a Groovy wrapper sample.
> integration test support for .kts pre/post hook scripts
>
>
> Key: MINVOKER-263
> URL: https://issues.apache.org/jira/browse/MINVOKER-263
> Project: Maven Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 3.2.1
>Reporter: Dariusz Kuc
>Priority: Minor
>
> It would be great if {{maven-invoker-plugin}} could support Kotlin script
> files (.kts). This would allow to write maven-plugin completely in Kotlin
> without the need to fallback to Groovy/Java for integration tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MINVOKER-169) install goal with extraArtifacts will download things which are not needed
[
https://issues.apache.org/jira/browse/MINVOKER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MINVOKER-169.
-
Resolution: Not A Problem
> install goal with extraArtifacts will download things which are not needed
> --
>
> Key: MINVOKER-169
> URL: https://issues.apache.org/jira/browse/MINVOKER-169
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.8
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> I have create integration test which use extraArtifacts
> org.apache.maven.plugins:maven-failsafe-plugin:2.17:maven-plugin which will
> download things like this:
> {code}
> Downloaded:
> http://localhost:8081/nexus/content/groups/public/org/apache/maven/plugins/maven-surefire-plugin/2.17/maven-surefire-plugin-2.17-site-source.zip
> (40 KB at 92.7 KB/sec)
> {code}
> This looks wrong.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MINVOKER-169) install goal with extraArtifacts will download things which are not needed
[
https://issues.apache.org/jira/browse/MINVOKER-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277477#comment-17277477
]
Sylwester Lachiewicz commented on MINVOKER-169:
---
That's a fully expected situation because
maven-failsafe-plugin:2.17:maven-plugin have that file in the dependency list:
https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-failsafe-plugin/2.17/maven-failsafe-plugin-2.17.pom
{code:java}
org.apache.maven.plugins
maven-surefire-plugin
2.17
zip
site-source
provided
{code}
> install goal with extraArtifacts will download things which are not needed
> --
>
> Key: MINVOKER-169
> URL: https://issues.apache.org/jira/browse/MINVOKER-169
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.8
>Reporter: Karl Heinz Marbaise
>Priority: Major
>
> I have create integration test which use extraArtifacts
> org.apache.maven.plugins:maven-failsafe-plugin:2.17:maven-plugin which will
> download things like this:
> {code}
> Downloaded:
> http://localhost:8081/nexus/content/groups/public/org/apache/maven/plugins/maven-surefire-plugin/2.17/maven-surefire-plugin-2.17-site-source.zip
> (40 KB at 92.7 KB/sec)
> {code}
> This looks wrong.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MINVOKER-258) file line endings encoding
[ https://issues.apache.org/jira/browse/MINVOKER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MINVOKER-258: -- Fix Version/s: 3.2.2 > file line endings encoding > -- > > Key: MINVOKER-258 > URL: https://issues.apache.org/jira/browse/MINVOKER-258 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 3.2.2 > > > In project some files have CRLF and some other LF. > What kind should be? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MINVOKER-274) Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal reflection
[
https://issues.apache.org/jira/browse/MINVOKER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277470#comment-17277470
]
Sylwester Lachiewicz commented on MINVOKER-274:
---
Maybe we can create an additional profile for Java 8 and overwrite the version
of Groove there? or this wrong direction?
> Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal
> reflection
> ---
>
> Key: MINVOKER-274
> URL: https://issues.apache.org/jira/browse/MINVOKER-274
> Project: Maven Invoker Plugin
> Issue Type: Improvement
> Environment: JDK9+
>Reporter: Bertrand Martin
>Priority: Major
> Labels: Java8
>
> h1. Problem
> Running integration tests with *maven-invoker-plugin* in JDK with version >=
> 9 (incl. OpenJDK 11, 14, 15, etc.) will generate these un-aesthetic messages:
> {noformat}
> [INFO] run post-build script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/d:/Dev2/maven/repository/org/codehaus/groovy/groovy-all/2.4.8/groovy-all-2.4.8.jar)
> to method java.lang.Object.clone()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> h1. Specification
> Use Groovy 3.x which solved all illegal accesses that were in 2.x.
> Most current version is:
> {code:xml}
> org.codehaus.groovy
> groovy-all
> 3.0.7
> pom
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6956) Ensure all Apache Maven repositories can handle build/consumer
[
https://issues.apache.org/jira/browse/MNG-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277469#comment-17277469
]
Robert Scholte commented on MNG-6956:
-
I don't know, we should rerun it. But it would be a good indicator if we're
ready to release the first alpha.
> Ensure all Apache Maven repositories can handle build/consumer
> --
>
> Key: MNG-6956
> URL: https://issues.apache.org/jira/browse/MNG-6956
> Project: Maven
> Issue Type: Task
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 4.0.x-candidate
>
>
> First run based on https://github.com/apache/maven-sources/tree/submodules
> {noformat}
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [36:34
> min]
> [INFO] Maven Artifact Resolver Ant Tasks 1.2.2-SNAPSHOT ... FAILURE [ 34.579
> s]
> [INFO] Maven Plugin Testing Mechanism 3.4.0-SNAPSHOT .. FAILURE [ 0.972
> s]
> [INFO] Maven :: Indexer Core 6.1.0-SNAPSHOT ... FAILURE [ 2.874
> s]
> [INFO] Maven Surefire Common 3.0.0-M6-SNAPSHOT FAILURE [ 0.544
> s]
> [INFO] Maven Surefire Integration Tests 3.0.0-M6-SNAPSHOT . FAILURE [ 1.499
> s]
> [INFO] Apache Maven AntRun Plugin 3.1.0-SNAPSHOT .. FAILURE [01:54
> min]
> [INFO] Apache Maven Enforcer API 3.0.0-M4-SNAPSHOT FAILURE [ 0.096
> s]
> [INFO] Apache Maven PDF Plugin 1.5.0-SNAPSHOT . FAILURE [01:49
> min]
> [INFO] Maven Plugin Metadata Model 3.6.1-SNAPSHOT . FAILURE [ 0.083
> s]
> [INFO] Maven Ant Mojo Support 3.6.1-SNAPSHOT .. FAILURE [ 0.440
> s]
> [INFO] Maven Beanshell Mojo Support 3.6.1-SNAPSHOT FAILURE [ 0.171
> s]
> [INFO] Maven Release APIs 3.0.0-SNAPSHOT .. FAILURE [ 0.243
> s]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6956) Ensure all Apache Maven repositories can handle build/consumer
[
https://issues.apache.org/jira/browse/MNG-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6956:
Fix Version/s: 4.0.x-candidate
> Ensure all Apache Maven repositories can handle build/consumer
> --
>
> Key: MNG-6956
> URL: https://issues.apache.org/jira/browse/MNG-6956
> Project: Maven
> Issue Type: Task
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 4.0.x-candidate
>
>
> First run based on https://github.com/apache/maven-sources/tree/submodules
> {noformat}
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [36:34
> min]
> [INFO] Maven Artifact Resolver Ant Tasks 1.2.2-SNAPSHOT ... FAILURE [ 34.579
> s]
> [INFO] Maven Plugin Testing Mechanism 3.4.0-SNAPSHOT .. FAILURE [ 0.972
> s]
> [INFO] Maven :: Indexer Core 6.1.0-SNAPSHOT ... FAILURE [ 2.874
> s]
> [INFO] Maven Surefire Common 3.0.0-M6-SNAPSHOT FAILURE [ 0.544
> s]
> [INFO] Maven Surefire Integration Tests 3.0.0-M6-SNAPSHOT . FAILURE [ 1.499
> s]
> [INFO] Apache Maven AntRun Plugin 3.1.0-SNAPSHOT .. FAILURE [01:54
> min]
> [INFO] Apache Maven Enforcer API 3.0.0-M4-SNAPSHOT FAILURE [ 0.096
> s]
> [INFO] Apache Maven PDF Plugin 1.5.0-SNAPSHOT . FAILURE [01:49
> min]
> [INFO] Maven Plugin Metadata Model 3.6.1-SNAPSHOT . FAILURE [ 0.083
> s]
> [INFO] Maven Ant Mojo Support 3.6.1-SNAPSHOT .. FAILURE [ 0.440
> s]
> [INFO] Maven Beanshell Mojo Support 3.6.1-SNAPSHOT FAILURE [ 0.171
> s]
> [INFO] Maven Release APIs 3.0.0-SNAPSHOT .. FAILURE [ 0.243
> s]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-978) Add option to use the 'quiet' (-q) flag
[ https://issues.apache.org/jira/browse/MSHARED-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277467#comment-17277467 ] Hudson commented on MSHARED-978: Build succeeded in Jenkins: Maven » Maven TLP » maven-invoker » master #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-invoker/job/master/19/ > Add option to use the 'quiet' (-q) flag > --- > > Key: MSHARED-978 > URL: https://issues.apache.org/jira/browse/MSHARED-978 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-invoker-3.1.0 > > > I would like to be able to use the -q flag when invoking Maven, to better > control output from the invocation > > I imagine it would look a lot like the other flags (e.g. > InvocationRequest.isDebug/setDebug) so > * boolean InvocationRequest.isQuiet() > * void InvocationRequest.setQuiet(boolean quiet) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MINVOKER-274) Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal reflection
[
https://issues.apache.org/jira/browse/MINVOKER-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MINVOKER-274:
--
Labels: Java8 (was: )
> Use Groovy 3.x to prevent Java9+ warnings about Groovy 2.x using illegal
> reflection
> ---
>
> Key: MINVOKER-274
> URL: https://issues.apache.org/jira/browse/MINVOKER-274
> Project: Maven Invoker Plugin
> Issue Type: Improvement
> Environment: JDK9+
>Reporter: Bertrand Martin
>Priority: Major
> Labels: Java8
>
> h1. Problem
> Running integration tests with *maven-invoker-plugin* in JDK with version >=
> 9 (incl. OpenJDK 11, 14, 15, etc.) will generate these un-aesthetic messages:
> {noformat}
> [INFO] run post-build script verify.groovy
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.codehaus.groovy.reflection.CachedClass
> (file:/d:/Dev2/maven/repository/org/codehaus/groovy/groovy-all/2.4.8/groovy-all-2.4.8.jar)
> to method java.lang.Object.clone()
> WARNING: Please consider reporting this to the maintainers of
> org.codehaus.groovy.reflection.CachedClass
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {noformat}
> h1. Specification
> Use Groovy 3.x which solved all illegal accesses that were in 2.x.
> Most current version is:
> {code:xml}
> org.codehaus.groovy
> groovy-all
> 3.0.7
> pom
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-978) Add option to use the 'quiet' (-q) flag
[ https://issues.apache.org/jira/browse/MSHARED-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MSHARED-978. Resolution: Fixed > Add option to use the 'quiet' (-q) flag > --- > > Key: MSHARED-978 > URL: https://issues.apache.org/jira/browse/MSHARED-978 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-invoker-3.1.0 > > > I would like to be able to use the -q flag when invoking Maven, to better > control output from the invocation > > I imagine it would look a lot like the other flags (e.g. > InvocationRequest.isDebug/setDebug) so > * boolean InvocationRequest.isQuiet() > * void InvocationRequest.setQuiet(boolean quiet) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-978) Add option to use the 'quiet' (-q) flag
[ https://issues.apache.org/jira/browse/MSHARED-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277461#comment-17277461 ] Sylwester Lachiewicz commented on MSHARED-978: -- Done with [3f8441fff0229a4feb30d604fcded8e859f3d835|https://gitbox.apache.org/repos/asf?p=maven-invoker.git;a=commit;h=3f8441fff0229a4feb30d604fcded8e859f3d835] > Add option to use the 'quiet' (-q) flag > --- > > Key: MSHARED-978 > URL: https://issues.apache.org/jira/browse/MSHARED-978 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-invoker-3.1.0 > > > I would like to be able to use the -q flag when invoking Maven, to better > control output from the invocation > > I imagine it would look a lot like the other flags (e.g. > InvocationRequest.isDebug/setDebug) so > * boolean InvocationRequest.isQuiet() > * void InvocationRequest.setQuiet(boolean quiet) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MSHARED-978) Add option to use the 'quiet' (-q) flag
[ https://issues.apache.org/jira/browse/MSHARED-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSHARED-978: Assignee: Sylwester Lachiewicz > Add option to use the 'quiet' (-q) flag > --- > > Key: MSHARED-978 > URL: https://issues.apache.org/jira/browse/MSHARED-978 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: maven-invoker-3.1.0 > > > I would like to be able to use the -q flag when invoking Maven, to better > control output from the invocation > > I imagine it would look a lot like the other flags (e.g. > InvocationRequest.isDebug/setDebug) so > * boolean InvocationRequest.isQuiet() > * void InvocationRequest.setQuiet(boolean quiet) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-7028) Upgrade Jansi to 2.0.1
[ https://issues.apache.org/jira/browse/MNG-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-7028: - Assignee: (was: Sylwester Lachiewicz) > Upgrade Jansi to 2.0.1 > -- > > Key: MNG-7028 > URL: https://issues.apache.org/jira/browse/MNG-7028 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: 4.0.x-candidate > > > Changelog: [https://github.com/fusesource/jansi/blob/master/changelog.md] > Performance optimizations, particularly for Windows > Utilize VIRTUAL_TERMINAL native feature in recent Windows versions > Added native libs for ARM, PPC architectures -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7028) Upgrade Jansi to 2.+
[ https://issues.apache.org/jira/browse/MNG-7028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-7028: -- Summary: Upgrade Jansi to 2.+ (was: Upgrade Jansi to 2.0.1) > Upgrade Jansi to 2.+ > > > Key: MNG-7028 > URL: https://issues.apache.org/jira/browse/MNG-7028 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: 4.0.x-candidate > > > Changelog: [https://github.com/fusesource/jansi/blob/master/changelog.md] > Performance optimizations, particularly for Windows > Utilize VIRTUAL_TERMINAL native feature in recent Windows versions > Added native libs for ARM, PPC architectures -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6855) Improve code quality by migration to java 8 syntax
[ https://issues.apache.org/jira/browse/MNG-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MNG-6855. - Resolution: Later > Improve code quality by migration to java 8 syntax > -- > > Key: MNG-6855 > URL: https://issues.apache.org/jira/browse/MNG-6855 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > The grouped tasks for many submitted corrections from the community. > > Also includes patches for reported improvements from different code quality > tools -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-6772:
-
Assignee: (was: Sylwester Lachiewicz)
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6855) Improve code quality by migration to java 8 syntax
[ https://issues.apache.org/jira/browse/MNG-6855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6855: -- Fix Version/s: (was: 4.0.0-alpha-1) (was: 4.0.0) > Improve code quality by migration to java 8 syntax > -- > > Key: MNG-6855 > URL: https://issues.apache.org/jira/browse/MNG-6855 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > The grouped tasks for many submitted corrections from the community. > > Also includes patches for reported improvements from different code quality > tools -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-6397) Maven Transitive Dependency Resolution Does Not Respect Repository Definition in pom.xml
[
https://issues.apache.org/jira/browse/MNG-6397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-6397:
-
Assignee: (was: Sylwester Lachiewicz)
> Maven Transitive Dependency Resolution Does Not Respect Repository Definition
> in pom.xml
>
>
> Key: MNG-6397
> URL: https://issues.apache.org/jira/browse/MNG-6397
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories, Dependencies, POM
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.6.0, 3.6.1, 3.6.3
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /usr/local/share/maven
> Java version: 1.8.0_161, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.10.5", arch: "x86_64", family: "mac"
>Reporter: Alan Czajkowski
>Priority: Critical
> Labels: maven
> Fix For: 4.0.x-candidate, waiting-for-feedback,
> wontfix-candidate, 4.0.0, 4.0.0-alpha-1
>
>
> _*Note:* I am trying to do a build behind a firewall which means I cannot
> access the Internet, I can only access my internal Maven repository inside my
> network, so:_
> - _grabbing artifacts from https://artifacts.example.com/repository/maven/
> works fine_
> - _grabbing artifacts from anywhere else fails due to firewall restrictions_
> Let's begin:
> My {{pom.xml}} has the following:
> {code:xml}
> ...
>
> ...
>
> org.springframework.boot
> spring-boot-starter-web
> 2.0.0.RELEASE
>
> ...
>
> ...
>
> ...
>
> central
> Public
> https://artifacts.example.com/repository/maven/
>
> true
>
>
> true
>
>
> ...
>
> ...
> {code}
> The {{dependency:tree}} for the {{spring-boot-starter-web}} is as follows:
> {code:java}
> +- org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE:compile
> | +-
> org.springframework.boot:spring-boot-starter-json:jar:2.0.0.RELEASE:compile
> | | +-
> com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.9.4:compile
> | | +-
> com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.9.4:compile
> | | \-
> com.fasterxml.jackson.module:jackson-module-parameter-names:jar:2.9.4:compile
> | +-
> org.springframework.boot:spring-boot-starter-tomcat:jar:2.0.0.RELEASE:compile
> | | \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:8.5.28:compile
> | +- org.hibernate.validator:hibernate-validator:jar:6.0.7.Final:compile
> | | +- javax.validation:validation-api:jar:2.0.1.Final:compile
> | | +- org.jboss.logging:jboss-logging:jar:3.3.0.Final:compile
> | | \- com.fasterxml:classmate:jar:1.3.1:compile
> | \- org.springframework:spring-web:jar:5.0.4.RELEASE:compile
> {code}
> How is it that the build fails as such:
> {code:java}
> ...
> Downloading:
> https://repo.spring.io/milestone/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://repo.spring.io/snapshot/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://dl.bintray.com/rabbitmq/maven-milestones/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> Downloading:
> https://repo.maven.apache.org/maven2/org/jboss/shrinkwrap/shrinkwrap-bom/1.2.3/shrinkwrap-bom-1.2.3.pom
> ...
> [ERROR] Failed to execute goal on project maven-multi-module-demo-backend:
> Could not resolve dependencies for project
> com.example.pipe:maven-multi-module-demo-backend:war:1.0.0-SNAPSHOT: Failed
> to collect dependencies at
> org.springframework.boot:spring-boot-starter-web:jar:2.0.0.RELEASE ->
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Failed to read
> artifact descriptor for
> org.hibernate.validator:hibernate-validator:jar:6.0.7.Final: Could not
> transfer artifact org.jboss.shrinkwrap:shrinkwrap-bom:pom:1.2.3 from/to
> spring-milestone (https://repo.spring.io/milestone): Connection reset ->
> [Help 1]
> ...
> {code}
> when I did not even reference this repo {{spring-milestone
> ([https://repo.spring.io/milestone])}} anywhere in my {{pom.xml}}?
> When you go down the Spring Boot rabbit hole (go into the
> {{spring-boot-starter-web}}'s {{pom.xml}} and then traverse up its parent-pom
> structure a few jumps) you'll eventually get to a parent-pom
> {{spring-boot-dependencies}} with this definition:
> {code:xml}
> ...
>
>
>
> false
>
> spring-milestone
> Spring Mil
[jira] [Assigned] (MPLUGIN-340) upgrade Ant version to 1.9.13
[ https://issues.apache.org/jira/browse/MPLUGIN-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MPLUGIN-340: Assignee: (was: Sylwester Lachiewicz) > upgrade Ant version to 1.9.13 > - > > Key: MPLUGIN-340 > URL: https://issues.apache.org/jira/browse/MPLUGIN-340 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade > Components: maven-plugin-tools-ant >Affects Versions: 3.5.2 >Reporter: Herve Boutemy >Priority: Major > > to benefit from > https://github.com/apache/ant/commit/857095da5153fd18504b46f276d84f1e76a66970 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-5222) Maven 3 no longer logs warnings about deprecated plugin parameters.
[ https://issues.apache.org/jira/browse/MNG-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-5222: - Assignee: (was: Sylwester Lachiewicz) > Maven 3 no longer logs warnings about deprecated plugin parameters. > --- > > Key: MNG-5222 > URL: https://issues.apache.org/jira/browse/MNG-5222 > Project: Maven > Issue Type: Wish > Components: Plugins and Lifecycle >Affects Versions: 3.0.3 >Reporter: Christian Schulte >Priority: Minor > Fix For: 4.0.x-candidate > > Time Spent: 10m > Remaining Estimate: 0h > > Providing a value for a deprecated plugin parameter, Maven 2.2.1 used to log > a warning. Currently Maven 3 does not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-5001) @readonly Mojo parameter annotation doesn't work any more
[
https://issues.apache.org/jira/browse/MNG-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-5001:
-
Assignee: (was: Sylwester Lachiewicz)
> @readonly Mojo parameter annotation doesn't work any more
> -
>
> Key: MNG-5001
> URL: https://issues.apache.org/jira/browse/MNG-5001
> Project: Maven
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 3.0-alpha-1, 3.0.2
>Reporter: Jochen Ehret
>Priority: Major
> Fix For: 4.0.x-candidate
>
> Attachments: log-maven-2.2.1.txt, log-maven-3.0.2.txt, pom.xml,
> readonlytest.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In Maven 2.2.1, the @readonly annotation works as described: You can't
> configure a Mojo parameter in the pom section. If you do, the
> build will fail:
> {noformat}[INFO] Error configuring: test:test-plugin. Reason: ERROR: Cannot
> override read-only parameter: testParameter in goal:
> test:dumpParameter{noformat}
> In Maven 3.0.2, the @readonly seems to have no effect:
> {noformat}[INFO] --- test-plugin:0.0.1-SNAPSHOT:dumpParameter (test-exec) @
> test-project ---
> testParameter: readonly parameter configured in pom{noformat}
> You can reproduce the behaviour with the attached example project. Log
> outputs for Maven 2.2.1 and 3.0.2 are also attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-5127) CLONE - Maven profile activation does not work when profile is defined in inherited 'parent' pom
[
https://issues.apache.org/jira/browse/MNG-5127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-5127:
-
Assignee: (was: Sylwester Lachiewicz)
> CLONE - Maven profile activation does not work when profile is defined in
> inherited 'parent' pom
>
>
> Key: MNG-5127
> URL: https://issues.apache.org/jira/browse/MNG-5127
> Project: Maven
> Issue Type: Bug
>Reporter: Scokart Gilles
>Priority: Major
> Attachments: daddy.zip, daddy2.zip
>
>
> The goal is to activate a maven profile based on OS user name.
> When I create a standalone project with a profile activation, it works,
> however, when I define the profile in a "parent" pom, it is never activated.
> this works:
> {code:xml}
> ...
>
> TONY
>
>
> user.name
> WINTONY
>
>
>
>
> {code}
>
> So in this case, my profile is activated based on my OS user name
> {noformat}
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building Proj1
> [INFO] task-segment: [help:active-profiles] (aggregator-style)
> [INFO]
>
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2':
> The following profiles are active:
> - TONY (source: pom)
> {noformat}
> --
> However, if I now have the profiles definition in the "parent" pom, it
> doesn't work when I build a child project
> So the child project references the parent pom containing the profiles and
> the activation, but when it is built,
> the profile is not activated
> {code:xml|title=PARENT POM}
> ...
>
>
> TONY
>
>
> user.name
> WINTONY
>
>
>
> ...
> {code}
> {code:xml|title=CHILD POM (the one being built)}
>
>
> com.capgemini.be.proj1
> parent
> 4.0.2
>
> {code}
> {noformat}
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [INFO] Building Proj1 Application
> [INFO] task-segment: [help:active-profiles] (aggregator-style)
> [INFO]
>
> [INFO] [help:active-profiles]
> [INFO]
> Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2':
> There are no active profiles.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6956) Ensure all Apache Maven repositories can handle build/consumer
[
https://issues.apache.org/jira/browse/MNG-6956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277455#comment-17277455
]
Sylwester Lachiewicz commented on MNG-6956:
---
Does this one still valid?
> Ensure all Apache Maven repositories can handle build/consumer
> --
>
> Key: MNG-6956
> URL: https://issues.apache.org/jira/browse/MNG-6956
> Project: Maven
> Issue Type: Task
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
>
> First run based on https://github.com/apache/maven-sources/tree/submodules
> {noformat}
> [INFO] Maven Core ITs suite 2.1-SNAPSHOT .. FAILURE [36:34
> min]
> [INFO] Maven Artifact Resolver Ant Tasks 1.2.2-SNAPSHOT ... FAILURE [ 34.579
> s]
> [INFO] Maven Plugin Testing Mechanism 3.4.0-SNAPSHOT .. FAILURE [ 0.972
> s]
> [INFO] Maven :: Indexer Core 6.1.0-SNAPSHOT ... FAILURE [ 2.874
> s]
> [INFO] Maven Surefire Common 3.0.0-M6-SNAPSHOT FAILURE [ 0.544
> s]
> [INFO] Maven Surefire Integration Tests 3.0.0-M6-SNAPSHOT . FAILURE [ 1.499
> s]
> [INFO] Apache Maven AntRun Plugin 3.1.0-SNAPSHOT .. FAILURE [01:54
> min]
> [INFO] Apache Maven Enforcer API 3.0.0-M4-SNAPSHOT FAILURE [ 0.096
> s]
> [INFO] Apache Maven PDF Plugin 1.5.0-SNAPSHOT . FAILURE [01:49
> min]
> [INFO] Maven Plugin Metadata Model 3.6.1-SNAPSHOT . FAILURE [ 0.083
> s]
> [INFO] Maven Ant Mojo Support 3.6.1-SNAPSHOT .. FAILURE [ 0.440
> s]
> [INFO] Maven Beanshell Mojo Support 3.6.1-SNAPSHOT FAILURE [ 0.171
> s]
> [INFO] Maven Release APIs 3.0.0-SNAPSHOT .. FAILURE [ 0.243
> s]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNGSITE-413) [CREATE] Maven Website (2021)
[ https://issues.apache.org/jira/browse/MNGSITE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNGSITE-413: - Description: Maven is such a formidable project that requires everyone: users/coders/contributors alike to properly THANK this ecosystem. As such, Tomitribe has happily volunteered to collaborate with the wonderful MavenCommitters on the creation of the Maven website in 2020/2021. Documentation on requirements [HERE |https://drive.google.com/drive/folders/1LZyHFJ4XD-mMkL8rcMnfoGj7GMhB0ZIJ?usp=sharing] was: Maven is such a formidable project that requires everyone: users/coders/contributors alike to properly THANK this ecosystem. As such, Tomitribe has happily volunteered to collaborate with the wonderful MavenCommitters on the creation of the Maven website in 2020. Documentation on requirements [HERE |https://drive.google.com/drive/folders/1LZyHFJ4XD-mMkL8rcMnfoGj7GMhB0ZIJ?usp=sharing] > [CREATE] Maven Website (2021) > -- > > Key: MNGSITE-413 > URL: https://issues.apache.org/jira/browse/MNGSITE-413 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Amelia Eiras >Assignee: Robert Scholte >Priority: Major > > Maven is such a formidable project that requires everyone: > users/coders/contributors alike to properly THANK this ecosystem. > As such, Tomitribe has happily volunteered to collaborate with the wonderful > MavenCommitters on the creation of the Maven website in 2020/2021. > Documentation on requirements [HERE > |https://drive.google.com/drive/folders/1LZyHFJ4XD-mMkL8rcMnfoGj7GMhB0ZIJ?usp=sharing] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNGSITE-413) [CREATE] Maven Website (2021)
[ https://issues.apache.org/jira/browse/MNGSITE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNGSITE-413: - Summary: [CREATE] Maven Website (2021) (was: [CREATE] Maven Website (2020)) > [CREATE] Maven Website (2021) > -- > > Key: MNGSITE-413 > URL: https://issues.apache.org/jira/browse/MNGSITE-413 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Amelia Eiras >Assignee: Robert Scholte >Priority: Major > > Maven is such a formidable project that requires everyone: > users/coders/contributors alike to properly THANK this ecosystem. > As such, Tomitribe has happily volunteered to collaborate with the wonderful > MavenCommitters on the creation of the Maven website in 2020. > Documentation on requirements [HERE > |https://drive.google.com/drive/folders/1LZyHFJ4XD-mMkL8rcMnfoGj7GMhB0ZIJ?usp=sharing] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MCOMPILER-376) Change default source/target to 1.7 (new minimum for JDK 12)
[ https://issues.apache.org/jira/browse/MCOMPILER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MCOMPILER-376: --- Fix Version/s: 3.9.0 > Change default source/target to 1.7 (new minimum for JDK 12) > > > Key: MCOMPILER-376 > URL: https://issues.apache.org/jira/browse/MCOMPILER-376 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.9.0 > > > With the statement "It must be possible to build a Hello World application > with the latest JDK + latest Maven + minimum pom" the default value for > source+target must be lifted to 1.7 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MRELEASE-1016:
--
Assignee: (was: Robert Scholte)
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Priority: Blocker
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] slachiewicz commented on pull request #421: Artifact.getPath() and .setPath()
slachiewicz commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-771985029 FYI: https://issues.apache.org/jira/browse/MNG-6444 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
[jira] [Updated] (MNG-6444) Internal code should prefer Path over File
[
https://issues.apache.org/jira/browse/MNG-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-6444:
--
Fix Version/s: 4.0.x-candidate
> Internal code should prefer Path over File
> --
>
> Key: MNG-6444
> URL: https://issues.apache.org/jira/browse/MNG-6444
> Project: Maven
> Issue Type: Task
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Labels: requires-java8
> Fix For: 4.0.x-candidate
>
>
> Goal is to replace all '{{new File(}}' appearances with Path / Paths
> https://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6112: -- Fix Version/s: 4.0.x-candidate > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-5901) Export org.eclipse.aether.util.artifact.SubArtifact
[
https://issues.apache.org/jira/browse/MNG-5901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-5901:
--
Fix Version/s: 4.0.x-candidate
> Export org.eclipse.aether.util.artifact.SubArtifact
> ---
>
> Key: MNG-5901
> URL: https://issues.apache.org/jira/browse/MNG-5901
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.3, 3.2.5, 3.3.1, 3.3.3
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.x-candidate, 4.x / Backlog
>
>
> Without exporting {{org.eclipse.aether.util.artifact.SubArtifact}} you will
> get a {{ClassNotFoundException}} when trying to deploy/upload attachments
> using the pure Aether solution by Eclipse.
> This is also the reason why maven-artifact-transfer shades this class, so
> this component will still work with all Maven versions between 3.1.1 and 3.3.3
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (DOXIA-361) Confluence: figure captions not rendered
[ https://issues.apache.org/jira/browse/DOXIA-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned DOXIA-361: -- Assignee: (was: Robert Scholte) > Confluence: figure captions not rendered > > > Key: DOXIA-361 > URL: https://issues.apache.org/jira/browse/DOXIA-361 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Confluence, Module - Xhtml >Affects Versions: 1.1 >Reporter: Lukas Theussl >Priority: Minor > Fix For: 2.0 > > Attachments: DOXIA-361.patch > > > Figure captions seem to go into the attribute, ie they are not > rendered in the xhtml output. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MINSTALL-164) Create GitHub Actions
[ https://issues.apache.org/jira/browse/MINSTALL-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MINSTALL-164: - Assignee: (was: Karl Heinz Marbaise) > Create GitHub Actions > - > > Key: MINSTALL-164 > URL: https://issues.apache.org/jira/browse/MINSTALL-164 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MINSTALL-164) Create GitHub Actions
[ https://issues.apache.org/jira/browse/MINSTALL-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MINSTALL-164: -- Fix Version/s: (was: 3.0.0) > Create GitHub Actions > - > > Key: MINSTALL-164 > URL: https://issues.apache.org/jira/browse/MINSTALL-164 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0-M1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MSOURCES-113) Store source encoding info in a standard file
[ https://issues.apache.org/jira/browse/MSOURCES-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MSOURCES-113: - Assignee: (was: Karl Heinz Marbaise) > Store source encoding info in a standard file > - > > Key: MSOURCES-113 > URL: https://issues.apache.org/jira/browse/MSOURCES-113 > Project: Maven Source Plugin > Issue Type: New Feature >Reporter: Fred Bricon >Priority: Major > Labels: intern > Fix For: next-release > > > It'd be nice if IDEs were able to automatically set proper source encoding > when attaching sources to project dependencies. > In eclipse/m2e, we tried to automatically detect encoding but it didn't work > out [https://git.eclipse.org/r/#/c/116390/] > A more reliable way would be to ensure the encoding info was stored inside > the source archive, so that IDEs could peek into it and ensure proper > settings. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MASSEMBLY-907) Dependencies are not included when run with mvn install
[ https://issues.apache.org/jira/browse/MASSEMBLY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MASSEMBLY-907: -- Assignee: (was: Karl Heinz Marbaise) > Dependencies are not included when run with mvn install > --- > > Key: MASSEMBLY-907 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-907 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.1.1 >Reporter: Lau Bakman >Priority: Major > Attachments: 310_install.log, 310_install_verbose.log, > 311_install.log, 311_install_verbose.log, 311_package_verbose.log, > assembly_deps.zip > > > We have just updated to version 3.1.1 due to MASSEMBLY-873 and have stumbled > upon a problem. > Our project is structured similar to the attached project. When we build our > project using "mvn clean package" the project is assembled correctly > including dependencies. If we on the other hand build our project using "mvn > clean install", only the top level jar files are assembled and all > dependencies are missing. > This worked in version 3.1.0. > Is this by design? And if it is, is there a way to revert to the old behavior? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-6096) Deprecate DefaultArtifactVersion class
[ https://issues.apache.org/jira/browse/MNG-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-6096: - Assignee: (was: Karl Heinz Marbaise) > Deprecate DefaultArtifactVersion class > -- > > Key: MNG-6096 > URL: https://issues.apache.org/jira/browse/MNG-6096 > Project: Maven > Issue Type: Task > Components: core >Affects Versions: needing-scrub-3.4.0-fallout >Reporter: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.x-candidate > > > The DefaultArtifactVersion class parses the version of the artifacts but in > many situations it does not work correctly. > Furthermore based on the references and hints given here: > https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNGSITE-266) Building for different Environments Documentation needs to be updated.
[ https://issues.apache.org/jira/browse/MNGSITE-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNGSITE-266: Assignee: (was: Karl Heinz Marbaise) > Building for different Environments Documentation needs to be updated. > -- > > Key: MNGSITE-266 > URL: https://issues.apache.org/jira/browse/MNGSITE-266 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Karl Heinz Marbaise >Priority: Major > > The [documentation to build for different > environments|http://maven.apache.org/guides/mini/guide-building-for-different-environments.html] > should be changed and updated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MWAR-354) Generate .gz side-car files for certain resources above WEB-INF/ or in WEB-INF/resources
[ https://issues.apache.org/jira/browse/MWAR-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MWAR-354: - Assignee: (was: Karl Heinz Marbaise) > Generate .gz side-car files for certain resources above WEB-INF/ or in > WEB-INF/resources > > > Key: MWAR-354 > URL: https://issues.apache.org/jira/browse/MWAR-354 > Project: Maven WAR Plugin > Issue Type: New Feature >Reporter: David Bullock >Priority: Major > Fix For: next-release > > > Apache Tomcat 8.0 will automatically send the pre-gzipped version of a > resource if it finds a .gz version of the file in the WAR. This is > beneficial since: 1) it saves on CPU cycles; 2) it can leverage the operating > system to send the file 'directly' from the disk to the network socket with > as little handling as possible in CPU/RAM. xref the 'Note' on the > 'compression' attribute documented at > https://tomcat.apache.org/tomcat-8.0-doc/config/http.html > So, I would like MWAR to do generate these pre-gzipped resources for me, at > build time. Obviously, it need only do so for certain static assets: an > initial 'by convention' would probably: > - include *.html, *.jpg, *.png, *.gif, *.css files under the WAR resource > root or subdirs > - but exclude those found under /WEB-INF/ > - except if they were specifically found under /WEB-INF/resources/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MEJB-82) Ability to add additional files to the META-INF directory
[ https://issues.apache.org/jira/browse/MEJB-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MEJB-82: Assignee: (was: Karl Heinz Marbaise) > Ability to add additional files to the META-INF directory > - > > Key: MEJB-82 > URL: https://issues.apache.org/jira/browse/MEJB-82 > Project: Maven EJB Plugin > Issue Type: New Feature >Affects Versions: 2.5 >Reporter: Alexandre Alvarez >Priority: Minor > > Currently it is possible to specify the ejb-jar.xml to use via the ejbJar > property. However, some containers require additional configuration files > (i.e. weblogic-ejb-jar.xml), so it would be helpful to be able to specify a > META-INF folder (with filters) to package. > > projA/META-INF/ejb-jar.xml > projA/META-INF/weblogic-ejb-jar.xml > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MEJB-33) Add support for fewer dependencies in client-jars
[ https://issues.apache.org/jira/browse/MEJB-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MEJB-33: Assignee: (was: Karl Heinz Marbaise) > Add support for fewer dependencies in client-jars > - > > Key: MEJB-33 > URL: https://issues.apache.org/jira/browse/MEJB-33 > Project: Maven EJB Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: tinne >Priority: Major > Fix For: more-investigation > > Attachments: ejb-client-packaging-problem-2014.zip, > ejb-client-packaging-problem.zip, make-client-separate.patch > > > Given a scenario, where several application tiers are installed on different > servers, are realized as EJB3 applications, and packaged using maven. > When configuring an ejb module, I give dependencies to all dependency jars > that are used to implement the features. However, they are currently all > added as dependency to the client-jar artifacts as well, so that unused > libraries are deployed on client servers. > I'd like to mark dependencies as server-jar only, e.g. by an > clientJarExclusions configuration element to the plugin, which takes a set of > exclusion elements like the exclusions-element in a dependency. These > dependencies should behave as compile-scope in the server- and provided-scope > in the client-jars. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SCM-796) Improve internal and user level documentation for the jazz provider
[ https://issues.apache.org/jira/browse/SCM-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned SCM-796: Assignee: (was: Chris Graham) > Improve internal and user level documentation for the jazz provider > --- > > Key: SCM-796 > URL: https://issues.apache.org/jira/browse/SCM-796 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jazz >Affects Versions: 1.9.2 > Environment: N/A >Reporter: Chris Graham >Priority: Trivial > > Update the internal java doc for the scm commands, referencing the V5 > releases. > Update the user level documentation, expanding and clarifying the usage of, > and best practices for the maven jazz provider. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6889) Mark command line option --legacy-local-repository as deprecated
[ https://issues.apache.org/jira/browse/MNG-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6889: -- Fix Version/s: (was: Issues to be reviewed for 4.x) 4.0.x-candidate > Mark command line option --legacy-local-repository as deprecated > > > Key: MNG-6889 > URL: https://issues.apache.org/jira/browse/MNG-6889 > Project: Maven > Issue Type: Task > Components: Command Line >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 4.0.x-candidate > > > We should at least mark this option as deprecated or even better remove this > option but this would be inconsistent to remove something which has not been > marked deprecated before. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6829) Remove commons-lang3 dependency
[
https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNG-6829:
--
Labels: close-pending (was: )
> Remove commons-lang3 dependency
> ---
>
> Key: MNG-6829
> URL: https://issues.apache.org/jira/browse/MNG-6829
> Project: Maven
> Issue Type: Sub-task
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Labels: close-pending
> Fix For: 4.0.x-candidate
>
>
> Currently we use {{commons-lang3}} for the following classes
> * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or
> {{maven-shared-utils}} or as I tested with self implementation
> * {{SystemUtils}} is only used in some tests which can simply replaced by
> using JUnit Jupiter with all the support it has.
> * {{Validate}} is a precondition class which checks for parameters etc. can
> be implemented very easily (done already to see how it works). Later this
> could be made part of {{maven-shared-utils}}.
> * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is
> used in {{ConsoleMavenTransferListener}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MJAR-265) Resources not copied
[ https://issues.apache.org/jira/browse/MJAR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MJAR-265: - Assignee: (was: Karl Heinz Marbaise) > Resources not copied > > > Key: MJAR-265 > URL: https://issues.apache.org/jira/browse/MJAR-265 > Project: Maven JAR Plugin > Issue Type: New Feature >Affects Versions: 3.1.2 > Environment: windows 7, Maven 3.3.9 Java version: 1.7.0_80 >Reporter: vincent c >Priority: Minor > Attachments: example.7z > > > I have a folder named *.metadata* that is in the target/classes folder. > But it is not copied to the jar archive. It looks like a default exclusion > filter is used. > It is working with version maven-jar-plugin:2.3 but version 2.4 and upper it > is not. > > The issue seams to be also discussed on > [stackoverflow|https://stackoverflow.com/questions/55514758/maven-jar-plugin-does-not-include-gitignore-file/55522970#55522970]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MENFORCER-329) Example for writing a custom rule should be upgraded
[ https://issues.apache.org/jira/browse/MENFORCER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17277445#comment-17277445 ] Sylwester Lachiewicz commented on MENFORCER-329: [~khmarbaise] any guideline how this should be changed? > Example for writing a custom rule should be upgraded > > > Key: MENFORCER-329 > URL: https://issues.apache.org/jira/browse/MENFORCER-329 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > > https://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MJAVADOC-618) Goal javadoc:aggregate fails with submodules packaged as war
[
https://issues.apache.org/jira/browse/MJAVADOC-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MJAVADOC-618:
--
Labels: close-pending (was: )
> Goal javadoc:aggregate fails with submodules packaged as war
>
>
> Key: MJAVADOC-618
> URL: https://issues.apache.org/jira/browse/MJAVADOC-618
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.1.0, 3.1.1
> Environment: - Java 11 or grater is required.
> - Submodules must be configured to be java modules. I've used
> 'Automatic-Module-Name' parameters with maven-jar-plugin
>Reporter: Andrea Del Bene
>Assignee: Olivier Lamy
>Priority: Major
> Labels: close-pending
> Fix For: waiting-for-feedback
>
> Attachments: maven-modular.zip
>
>
> If we have a submodule project producing a war archive, {{javadoc:aggregate}}
> fails with the following message:
> {noformat}
> [WARNING] Only outputDirectories and jars are accepted on the path
> [ERROR] Error while creating javadoc report: Only outputDirectories and jars
> are accepted on the path
> java.lang.IllegalArgumentException: Only outputDirectories and jars are
> accepted on the path
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:333)
> at org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePath
> (LocationManager.java:139)
> at
> org.apache.maven.plugins.javadoc.AbstractJavadocMojo.addJavadocOptions
> (AbstractJavadocMojo.java:5001)
> {noformat}
> After some investigations it seems it tries to pass the war package to
> LocationManager.resolvePath.
> I've added a quickstart project to reproduce the problem. Just run:
> {{mvn package javadoc:aggregate}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MRELEASE-594) release:prepare should stop when there is snapshots in dependencies management
[ https://issues.apache.org/jira/browse/MRELEASE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MRELEASE-594: - Assignee: (was: Olivier Lamy) > release:prepare should stop when there is snapshots in dependencies management > -- > > Key: MRELEASE-594 > URL: https://issues.apache.org/jira/browse/MRELEASE-594 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Reporter: Thomas Bruyelle >Priority: Major > Fix For: Backlog > > Attachments: allowUnusedSnapshotsInDependencyManagement.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MSHADE-286) Shading fails when a dependency's main artifact does not exist
[
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MSHADE-286:
---
Assignee: (was: Mark Struberg)
> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Shading fails when a dependency's main artifact does not exist, see the
> methods {{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
> A similar existence check (luckily) does not exist for the other artifacts:
> test jar, sources, and test sources.
> This was done intentionally, but it's overly strict because it prohibits a
> legitimate use case: some projects don't produce a main artifact, but only
> e.g. a test artifact.
> Such projects can't be shaded because of this existence check.
> It would be better to:
> - Get rid of this check, or at least relax it, such that shading also works
> for projects that don't produce a main artifact.
> - Complete the symmetry between jar, test jar, sources and test sources by
> adding a {{shadeJar}} boolean with default value {{true}}, which disables
> shading of main artifacts in a similar way {{shadeTestJar}},
> {{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow
> shading to disable creation of a main artifact altogether, even when the
> dependencies _do_ have a main artifact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MENFORCER-267) Upgrade to make Maven 3.1+
[ https://issues.apache.org/jira/browse/MENFORCER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MENFORCER-267: --- Fix Version/s: 3.0.0-M4 > Upgrade to make Maven 3.1+ > -- > > Key: MENFORCER-267 > URL: https://issues.apache.org/jira/browse/MENFORCER-267 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-M3 >Reporter: Karl Heinz Marbaise >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.0.0, 3.0.0-M4 > > > * maven-dependency-tree needs to be updated to 3.0.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MENFORCER-267) Upgrade to make Maven 3.1+
[ https://issues.apache.org/jira/browse/MENFORCER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MENFORCER-267: -- Assignee: Sylwester Lachiewicz (was: Karl Heinz Marbaise) > Upgrade to make Maven 3.1+ > -- > > Key: MENFORCER-267 > URL: https://issues.apache.org/jira/browse/MENFORCER-267 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-M3 >Reporter: Karl Heinz Marbaise >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.0.0 > > > * maven-dependency-tree needs to be updated to 3.0.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-5666) Divide lifecycle in prePhases, phases and postPhases
[
https://issues.apache.org/jira/browse/MNG-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-5666:
-
Assignee: (was: Jason van Zyl)
> Divide lifecycle in prePhases, phases and postPhases
>
>
> Key: MNG-5666
> URL: https://issues.apache.org/jira/browse/MNG-5666
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Priority: Major
> Fix For: 4.x / Backlog
>
>
> Original proposal
> {quote}
> PROPOSAL 1: PerProject and PerPhase Executions
>
> I've recently introduced the installAtEnd/deployAtEnd as an experimental
> feature which should improve the behavior of Maven without having to wait for
> the implementation in Maven Core, which would have a huge impact.
> The reason is that you only want to install and/or deploy only after all
> modules have been build and verified successfully.
> This feature works for most projects, however there are cases which cannot be
> solved by the plugin solution and require a change in the handling of
> lifecycles in Maven Core.
> Up unto the verify-phase you want to execute all phases per project, whereas
> the install and deploy should be executed per phase.
> Consider a root project with 2 modules, these should be executed like this
>
> root : validate ... verify
> module1: validate ... verify
> module2: validate ... verify
> root : install
> module1: install
> module2: install
> root : deploy
> module1: deploy
> module2: deploy
> {quote}
> After one of the google hangout session we came up with the following idea:
> divide the build in pre-build, build and post-build
> First the {{pre-build}} would do a validate of the whole project.
> The {{build}} runs from {{initialize}} up to {{verify}}
> The {{post-build}} would handle the distribution, being {{install}}/{{deploy}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-5592) Maven dependency resolution locks up
[
https://issues.apache.org/jira/browse/MNG-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MNG-5592:
-
Assignee: (was: igorfie)
> Maven dependency resolution locks up
>
>
> Key: MNG-5592
> URL: https://issues.apache.org/jira/browse/MNG-5592
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.1.1, 3.2.1, 3.5.0
> Environment: OS/X, Java 7 and Java 8
>Reporter: Mark Derricutt
>Priority: Major
> Attachments: MNG-5592.zip, MNG-5592_testcase.zip,
> MNG-5592_testcase_locked_nocyclic.zip, mjml-cli.log, mng-5592-simplified.zip,
> mng-5592.zip
>
>
> One one of my larger integration projects that involves A LOT of version
> ranges across a broad range of dependencies I'm seeing that Maven locks up
> resolving dependencies.
> I've recently seen this in 3.1.1 but it's happening more and more often under
> 3.2.1.
> It appears that Eclipse Aether is falling into a circular loop somewhere and
> locking up.
> {code}
> "main" #1 prio=5 os_prio=31 tid=0x7f966b001000 nid=0x1903 runnable
> [0x000103559000]
>java.lang.Thread.State: RUNNABLE
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver$ConflictContext.isIncluded(ConflictResolver.java:1062)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector$1.accept(NearestVersionSelector.java:145)
> at
> org.eclipse.aether.util.graph.visitor.PathRecordingDependencyVisitor.visitEnter(PathRecordingDependencyVisitor.java:88)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:324)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.graph.DefaultDependencyNode.accept(DefaultDependencyNode.java:329)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.newFailure(NearestVersionSelector.java:149)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.backtrack(NearestVersionSelector.java:111)
> at
> org.eclipse.aether.util.graph.transformer.NearestVersionSelector.selectVersion(NearestVersionSelector.java:84)
> at
> org.eclipse.aether.util.graph.transformer.ConflictResolver.transformGraph(ConflictResolver.java:187)
> at
> org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:275)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:317)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:195)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:127)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:257)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:200)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.Sing
[jira] [Assigned] (MNG-5665) Advanced Lifecycle Handling
[ https://issues.apache.org/jira/browse/MNG-5665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-5665: - Assignee: (was: Jason van Zyl) > Advanced Lifecycle Handling > --- > > Key: MNG-5665 > URL: https://issues.apache.org/jira/browse/MNG-5665 > Project: Maven > Issue Type: Bug > Components: FDPFC, Plugins and Lifecycle >Reporter: Robert Scholte >Priority: Major > Labels: needs-discussion > Fix For: 4.x / Backlog > > > These are a couple of improvements, which will improve the behavior of Maven > regarding lifecycles -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SCM-949) xml.listStyle' for field element is deprecated: use 'xml.itemsStyle'
[ https://issues.apache.org/jira/browse/SCM-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated SCM-949: - Fix Version/s: 1.11.3 > xml.listStyle' for field element is deprecated: use 'xml.itemsStyle' > > > Key: SCM-949 > URL: https://issues.apache.org/jira/browse/SCM-949 > Project: Maven SCM > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 1.11.3 > > > Several warnings like this in the build > > [INFO] Working on model: src/main/mdo/maven-scm-local-metadata.mdo > [WARNING] attribute 'xml.listStyle' for field element is deprecated: use > 'xml.itemsStyle' in association instead -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SCM-949) xml.listStyle' for field element is deprecated: use 'xml.itemsStyle'
[ https://issues.apache.org/jira/browse/SCM-949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed SCM-949. Resolution: Fixed > xml.listStyle' for field element is deprecated: use 'xml.itemsStyle' > > > Key: SCM-949 > URL: https://issues.apache.org/jira/browse/SCM-949 > Project: Maven SCM > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Fix For: 1.11.3 > > > Several warnings like this in the build > > [INFO] Working on model: src/main/mdo/maven-scm-local-metadata.mdo > [WARNING] attribute 'xml.listStyle' for field element is deprecated: use > 'xml.itemsStyle' in association instead -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MSHARED-916) Require Maven 3.1.1 (drop dependency to Maven 3.0)
[ https://issues.apache.org/jira/browse/MSHARED-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MSHARED-916: - Summary: Require Maven 3.1.1 (drop dependency to Maven 3.0) (was: Require Maven 3+) > Require Maven 3.1.1 (drop dependency to Maven 3.0) > -- > > Key: MSHARED-916 > URL: https://issues.apache.org/jira/browse/MSHARED-916 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-dependency-analyzer >Reporter: Sylwester Lachiewicz >Assignee: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (SUREFIRE-1603) Pass TestReporter entries to the reports generated by Surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned SUREFIRE-1603:
--
Assignee: (was: Christian Stein)
> Pass TestReporter entries to the reports generated by Surefire
> --
>
> Key: SUREFIRE-1603
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1603
> Project: Maven Surefire
> Issue Type: Improvement
> Components: JUnit 5.x support
>Affects Versions: 2.22.1, 3.0.0-M1
>Reporter: John Knight
>Priority: Minor
> Fix For: Backlog
>
>
> Using JUnit 5.31 with the following configuration:
> {noformat}
>
> junit.jupiter.execution.parallel.enabled = true
> junit.jupiter.execution.parallel.config.dynamic.factor = 8
> junit.jupiter.extensions.autodetection.enabled = true
> {noformat}
> and the following tests (for demonstration purposes)
> {noformat}
> public class AppTest
> {
> @Test
> public void mogbyTrue()
> {
> for (int i = 0; i < 5; i++) {
> System.out.println("mogby " + Thread.currentThread().getName());
> }
> assertTrue( false );
> }
> @Test
> public void kermitTrue()
> {
> for (int i = 0; i < 5; i++) {
> System.out.println("kermit " + Thread.currentThread().getName());
> }
> assertTrue( false );
> }{noformat}
> When the tests are executed via mvn test, the messages from both tests appear
> under the output for the first test:
> {noformat}
>
> https://junit.org/junit5/docs/snapshot/user-guide/#running-tests-capturing-output]
> - The output for both tests is still captured within the field
> of the first test, but in a different order:
> {noformat}
> {noformat}
> The original use case for this, is that we have a whole suite of tests
> running via Jenkins, so when tests fail, it's really difficult to see what
> the actual problem is, as the logging is out of sync.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
