[jira] [Updated] (MCOMPILER-525) Incremental recompile incorrect detection of dependency change
[ https://issues.apache.org/jira/browse/MCOMPILER-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Solórzano updated MCOMPILER-525: -- Affects Version/s: 3.10.0 3.9.0 3.8.1 > Incremental recompile incorrect detection of dependency change > -- > > Key: MCOMPILER-525 > URL: https://issues.apache.org/jira/browse/MCOMPILER-525 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1, 3.9.0, 3.10.0, 3.10.1 >Reporter: Jorge Solórzano >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > I have just hit an issue running the ITs of maven-jar-plugin, specifically > the *MJAR-70-no-recreation* test on Maven 3.9.0-SNAPSHOT. > Trying to debug the issue I just found out that the issue is not related to > Maven 3.9.0-SNAPSHOT but the real issue seems related to the > maven-compiler-plugin used by default on that version. > maven-compiler-plugins tries to detect changes on incremental compilation > running *isDependencyChanged()* which in turn executes *hasNewFile()* but > during the same run of maven, if the compile phase is run twice it would not > detect correctly that nothing has changed since is just evaluating the file > time of the class but the class ends up being newer than the buildStartTime, > so this causes the recompilation. > My proposal is to add a step to set the last modification time if the > incremental compilation is enabled and that way it will use the exact same > time than the buildStartTime() from maven. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
Christoph Läubrich created MNG-7716:
---
Summary: ConcurrencyDependencyGraph deadlock if no root can be
selected
Key: MNG-7716
URL: https://issues.apache.org/jira/browse/MNG-7716
Project: Maven
Issue Type: Bug
Reporter: Christoph Läubrich
At Tycho we got a bug-report that results in a deadlock when calling the
tycho-version-plugin:
https://github.com/eclipse-tycho/tycho/issues/2169
I debugged the problem and it seems that ConcurrencyDependencyGraph is actually
the culprit here because it can return an empty list of projects to initially
build. As no builds are scheduled then the code in the MultiThreadedBuilder
waits forever for the result, this is what happening here:
* There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT ->
[org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code}
* This segment has a transitive reactor dependency to {code}MavenProject:
org.faktorips:codequality-config:23.6.0-SNAPSHOT @
faktorips.base/codequality-config/pom.xml{code} (this is not a problem because
we only execute a reactor=true mojo!)
* So now the loop finds that there is no "independent" project and returns an
empty list
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-391) annotationProcessorPaths have to follow dependencyManagement rules
[ https://issues.apache.org/jira/browse/MCOMPILER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17696485#comment-17696485 ] Petr Široký commented on MCOMPILER-391: --- https://github.com/apache/maven-compiler-plugin/pull/180 is now ready for review. Any feedback / comments would be more than welcome. > annotationProcessorPaths have to follow dependencyManagement rules > -- > > Key: MCOMPILER-391 > URL: https://issues.apache.org/jira/browse/MCOMPILER-391 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.0 >Reporter: Stanislav Spiridonov >Priority: Blocker > Attachments: MCOMPILER-391.zip > > > # Use the version from dependency management > # Respect the exclude (blocker for me) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MENFORCER-469) banTransitiveDependencies: failing if a transitive dependencies has another version than the resolved one
Jérôme Joslet created MENFORCER-469:
---
Summary: banTransitiveDependencies: failing if a transitive
dependencies has another version than the resolved one
Key: MENFORCER-469
URL: https://issues.apache.org/jira/browse/MENFORCER-469
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 3.2.1
Reporter: Jérôme Joslet
Attachments: pom.xml
See the attached [^pom.xml] that reproduces the problem.
The verbose dependency tree ({{{}mvn dependency:tree -Dverbose{}}}) of the
project is:
{code:java}
com.example.jjo:enforcer-plugin-test:pom:1.0.0-SNAPSHOT
+- commons-beanutils:commons-beanutils:jar:1.8.3:compile
| \- (commons-logging:commons-logging:jar:1.1.1:compile - omitted for conflict
with 1.2)
\- commons-logging:commons-logging:jar:1.2:compile {code}
As you can see, I use a higher version of the
{{commons-logging:commons-logging}} artifact in the project. Maven resolves the
1.2 version as expected and 1.1.1 is omitted.
The version 3.2.1 of the enforcer rule fails with the following message:
{code:java}
[ERROR] Rule 0:
org.apache.maven.enforcer.rules.dependency.BanTransitiveDependencies failed
with message:
[ERROR] com.example.jjo:enforcer-plugin-test:pom:1.0.0-SNAPSHOT
[ERROR] commons-beanutils:commons-beanutils:jar:1.8.3 has transitive
dependencies:
[ERROR] commons-logging:commons-logging:jar:1.1.1 has transitive
dependencies:{code}
It shouldn't consider the {{commons-logging:commons-logging:jar:1.1.1}}
artifact as a transitive dependencies since the version 1.2 is resolved instead.
The version 3.1.0 of the enforcer rule works as expected with this project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGIN-456) maven-plugin-plugin:3.2:descriptor throws index out of bounds
Christoph Läubrich created MPLUGIN-456:
--
Summary: maven-plugin-plugin:3.2:descriptor throws index out of
bounds
Key: MPLUGIN-456
URL: https://issues.apache.org/jira/browse/MPLUGIN-456
Project: Maven Plugin Tools
Issue Type: Bug
Reporter: Christoph Läubrich
I currently try to add a simple plugin for testing purpose, but I always get
when executing
mvn clean verify
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor
(default-descriptor) on project org.eclipse.m2e.tests.plugin: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index 1381
out of bounds for length 404 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor
(default-descriptor) on project org.eclipse.m2e.tests.plugin: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index 1381
out of bounds for length 404
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:375)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
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:294)
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:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
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.plugin.PluginExecutionException: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index 1381
out of bounds for length 404
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:370)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
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:294)
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:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
[jira] [Updated] (MPLUGIN-456) maven-plugin-plugin:3.2:descriptor throws index out of bounds
[
https://issues.apache.org/jira/browse/MPLUGIN-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Läubrich updated MPLUGIN-456:
---
Description:
I currently try to add a simple plugin for testing purpose, but I always get
when executing
mvn clean verify
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor
(default-descriptor) on project org.eclipse.m2e.tests.plugin: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index 1381
out of bounds for length 404 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor
(default-descriptor) on project org.eclipse.m2e.tests.plugin: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index 1381
out of bounds for length 404
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:375)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
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:294)
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:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
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.plugin.PluginExecutionException: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index 1381
out of bounds for length 404
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:370)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
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:294)
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:960)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
[jira] [Commented] (MPLUGIN-456) maven-plugin-plugin:3.2:descriptor throws index out of bounds
[
https://issues.apache.org/jira/browse/MPLUGIN-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698556#comment-17698556
]
Christoph Läubrich commented on MPLUGIN-456:
Any plan tu update this with maven? its a bit strange that isuses an outdated
version that makes errors...
> maven-plugin-plugin:3.2:descriptor throws index out of bounds
> -
>
> Key: MPLUGIN-456
> URL: https://issues.apache.org/jira/browse/MPLUGIN-456
> Project: Maven Plugin Tools
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> I currently try to add a simple plugin for testing purpose, but I always get
> when executing
> mvn clean verify
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor
> (default-descriptor) on project org.eclipse.m2e.tests.plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index
> 1381 out of bounds for length 404 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor
> (default-descriptor) on project org.eclipse.m2e.tests.plugin: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index
> 1381 out of bounds for length 404
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:375)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> 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:294)
> 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:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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.plugin.PluginExecutionException: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor failed: Index
> 1381 out of bounds for length 404
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:370)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> 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
[jira] [Created] (MWRAPPER-103) Failed to validate Maven Wrapper SHA-256 on Windows
Jorge Solórzano created MWRAPPER-103:
Summary: Failed to validate Maven Wrapper SHA-256 on Windows
Key: MWRAPPER-103
URL: https://issues.apache.org/jira/browse/MWRAPPER-103
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Scripts
Affects Versions: 3.2.0
Reporter: Jorge Solórzano
When *wrapperSha256Sum* is set on GitHub Actions for the Windows platform, the
script fails as is unable to validate the wrapper jar.
I don't currently have access to a Windows machine, but this is failing for the
following GH Actions configuration:
{noformat}
Operating System: Microsoft Windows Server 2022 10.0.20348
Datacenter
Image: windows-202
Version: 20230307.2
Included Software:
https://github.com/actions/runner-images/blob/win22/20230307.2/images/win/Windows2022-Readme.md
Image Release:
https://github.com/actions/runner-images/releases/tag/win22%2F20230307.2
{noformat}
{noformat}
./mvnw $COMMON_MAVEN_ARGS $JVM_TEST_MAVEN_ARGS install -pl
'integration-tests/devtools'
shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"
env:
LANG: en_US.UTF-8
COMMON_MAVEN_ARGS: -e -B --settings .github/mvn-settings.xml
--fail-at-end
NATIVE_TEST_MAVEN_ARGS: -Dtest-containers -Dstart-containers
-Dquarkus.native.native-image-xmx=5g -Dnative -Dnative.surefire.skip
-Dformat.skip -Dno-descriptor-tests install -DskipDocs
JVM_TEST_MAVEN_ARGS: -Dtest-containers -Dstart-containers -Dformat.skip
-DskipDocs -Dquarkus.test.hang-detection-timeout=60
JAVA_HOME:
C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\11.0.18-10\x64
JAVA_HOME_11_X64:
C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\11.0.18-10\x64
Get-FileHash : The term 'Get-FileHash' is not recognized as the name of a
cmdlet, function, script file, or operable
program. Check the spelling of the name, or if a path was included, verify
that the path is correct and try again.
At line:1 char:13
+ &{ $hash = (Get-FileHash "D:\a\quarkus\quarkus\.mvn\wrapper\maven-wra ...
+
+ CategoryInfo : ObjectNotFound: (Get-FileHash:String) [],
CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Error: Failed to validate Maven wrapper SHA-256, your Maven wrapper might
be compromised.
Investigate or delete D:\a\quarkus\quarkus\.mvn\wrapper\maven-wrapper.jar
to attempt a clean download.
If you updated your Maven version, you need to update the specified
wrapperSha256Sum property.{noformat}
Also, using when using Git Bash:
{noformat}
./mvnw $COMMON_MAVEN_ARGS install -Dsurefire.timeout=1200 -pl
!integration-tests/gradle -pl !integration-tests/maven -pl
!integration-tests/devtools -pl !docs -DskipDocs -Dformat.skip -Dincremental
-Dgib.disableSelectedProjectsHandling -Dgib.untracked=false
-Dgib.uncommitted=false -Dgib.referenceBranch=origin/main
-Dgib.disableIfReferenceBranchMatches='origin/\d+\.\d+'
shell: C:\Program Files\Git\bin\bash.EXE --noprofile --norc -e -o pipefail {0}
env: LANG: en_US.UTF-8 COMMON_MAVEN_ARGS: -e -B
--settings .github/mvn-settings.xml --fail-at-end
NATIVE_TEST_MAVEN_ARGS: -Dtest-containers -Dstart-containers
-Dquarkus.native.native-image-xmx=5g -Dnative -Dnative.surefire.skip
-Dformat.skip -Dno-descriptor-tests install -DskipDocs
JVM_TEST_MAVEN_ARGS: -Dtest-containers -Dstart-containers -Dformat.skip
-DskipDocs -Dquarkus.test.hang-detection-timeout=60
MAVEN_OPTS: -Xmx2g -XX:MaxMetaspaceSize=1g
-Xlog:gc*=debug:file=windows-java-17.txt
JAVA_HOME: C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\17.0.6-10\x64
JAVA_HOME_17_X64:
C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\17.0.6-10\x64
Error: Failed to validate Maven wrapper SHA-256, your Maven wrapper might be
compromised. Investigate or delete
/d/a/quarkus/quarkus/.mvn/wrapper/maven-wrapper.jar to attempt a clean
download.
If you updated your Maven version, you need to update the specified
wrapperSha256Sum property.
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-364) requireFilesExist rule should be case sensitive
[
https://issues.apache.org/jira/browse/MENFORCER-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17700849#comment-17700849
]
Torbjörn Svensson commented on MENFORCER-364:
-
The change in
[335f26e39d1f20e157c46485481e36f858135a14|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commit;h=335f26e39d1f20e157c46485481e36f858135a14]
causes a regression when the file that is to be checked is a symbolic link.
In the case of a symbolic link, the java.io.File#getCanonicalFile() returns the
fully resolved java.io.File object containing the target of the symbolic link
and not the link itself.
> requireFilesExist rule should be case sensitive
> ---
>
> Key: MENFORCER-364
> URL: https://issues.apache.org/jira/browse/MENFORCER-364
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Johannes Goebel
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.0.0
>
>
> When using the enforcer plugin with a configuration using the
> {{requireFilesExist}} rule, as follows, the case of the existence of files
> cannot be enforced case sensitive.
> {code:xml}
>
> org.apache.maven.plugins
> maven-enforcer-plugin
> 3.0.0-M3
>
>
> enforce-files-exist
>
> enforce
>
>
>
>
>
> src/main/resources/i18n_de.properties
>
>
>
> true
>
>
>
>
> {code}
> For example, if the file {{src/main/resources/i18n_DE.properties}} exists,
> but not {{src/main/resources/i18n_de.properties}} the execution of the plugin
> will succeed.
> Unfortunately in my use case, this is exactly the requirement. I have not
> found a way to enforce case sensitivity for this rule.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702076#comment-17702076
]
Christoph Läubrich commented on MNG-7038:
-
I think instead of rootdir, "maven.config.directory" would be more suitable (as
it contains maven.config, jvm.config and extensions.xml, possibly extension
specific config files as well)
"topdir" also sounds strange maybe better something like
"maven.execution.directory"
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702116#comment-17702116
]
Christoph Läubrich commented on MNG-7038:
-
Not sure what "dangerous" means, of course one can always construct cases that
might break something, I usually try to avoid such "tricks" and layout / write
my build as I write code: Using patterns that are clear and can be understood
without doubts.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7743) Make the build work on JDK 20
Petr Široký created MNG-7743:
Summary: Make the build work on JDK 20
Key: MNG-7743
URL: https://issues.apache.org/jira/browse/MNG-7743
Project: Maven
Issue Type: Task
Components: Bootstrap & Build
Reporter: Petr Široký
When building Maven (from master and 3.9.x branches) using the latest JDK 20 RC
(which is very likely going to be promoted to GA), I am seeing the following
test error:
{code:java}
[ERROR]
org.apache.maven.project.ProjectBuilderTest.testLocationTrackingResolution
Time elapsed: 0.015 s <<< ERROR!
java.lang.IllegalStateException: java.net.MalformedURLException: Illegal
character found in host: '{'
at
org.apache.maven.repository.TestRepositoryConnector.(TestRepositoryConnector.java:56)
at
org.apache.maven.repository.TestRepositoryConnectorFactory.newInstance(TestRepositoryConnectorFactory.java:39)
at
org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.newRepositoryConnector(DefaultRepositoryConnectorProvider.java:121)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:515)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:433)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:261)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:277)
at
org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:167)
at
org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:214)
at
org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:279)
at
org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1517)
at
org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:1339)
at
org.apache.maven.model.building.DefaultModelBuilder.readEffectiveModel(DefaultModelBuilder.java:798)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:896)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:664)
at
org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:645)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:167)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:130)
at
org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:126)
at
org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:110)
at
org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:106)
at
org.apache.maven.project.ProjectBuilderTest.testLocationTrackingResolution(ProjectBuilderTest.java:357)
...
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
Caused by: java.net.MalformedURLException: Illegal character found in host: '{'
at java.base/java.net.URL.(URL.java:798)
at java.base/java.net.URL.(URL.java:646)
at java.base/java.net.URL.(URL.java:582)
at
org.apache.maven.repository.TestRepositoryConnector.(TestRepositoryConnector.java:54)
... 91 more
Caused by: java.lang.IllegalArgumentException: Illegal character found in host:
'{'
at java.base/java.net.URLStreamHandler.setURL(URLStreamHandler.java:522)
at
java.base/java.net.URLStreamHandler.parseURL(URLStreamHandler.java:325)
at java.base/sun.net.www.protocol.file.Handler.parseURL(Handler.java:56)
at java.base/java.net.URL.(URL.java:793)
{code}
This seems to be related to [https://bugs.openjdk.org/browse/JDK-8293590] which
moved some of the URL validation to the constructor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702214#comment-17702214
]
Christoph Läubrich commented on MNG-7038:
-
> Having a `.mvn` directory gives a clear and simple definition and computation.
I agree with that, if it is documented that if one wants to use the property it
would be fine I think and as it already *is* defined to work that way
(mven.config, jvm.config, extensions.xml) the only "missing link" is making it
official how to use it, and that's what this is about, I don't really see why
we now need a whole set of things name them in different ways and have complex
definitions.
Its also quite easy to just create an empty folder if one just likes to get it
defined.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7743) Make the build work on JDK 20
[
https://issues.apache.org/jira/browse/MNG-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702252#comment-17702252
]
Petr Široký commented on MNG-7743:
--
The repo URL {code}file://${basedir}/../../src/test/remote-repo{code} is and
it coming from
https://github.com/apache/maven/blob/6178f6ed8637bfa2b7765e0f74eb51c4fa1224d9/maven-core/src/test/projects/project-builder/MNG-7648/pom.xml#L16
> Make the build work on JDK 20
> -
>
> Key: MNG-7743
> URL: https://issues.apache.org/jira/browse/MNG-7743
> Project: Maven
> Issue Type: Task
> Components: Bootstrap & Build
>Reporter: Petr Široký
>Priority: Minor
>
> When building Maven (from master and 3.9.x branches) using the latest JDK 20
> RC (which is very likely going to be promoted to GA), I am seeing the
> following test error:
> {code:java}
> [ERROR]
> org.apache.maven.project.ProjectBuilderTest.testLocationTrackingResolution
> Time elapsed: 0.015 s <<< ERROR!
> java.lang.IllegalStateException: java.net.MalformedURLException: Illegal
> character found in host: '{'
> at
> org.apache.maven.repository.TestRepositoryConnector.(TestRepositoryConnector.java:56)
> at
> org.apache.maven.repository.TestRepositoryConnectorFactory.newInstance(TestRepositoryConnectorFactory.java:39)
> at
> org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.newRepositoryConnector(DefaultRepositoryConnectorProvider.java:121)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:515)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:433)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:261)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:277)
> at
> org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:167)
> at
> org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:214)
> at
> org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:279)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1517)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:1339)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readEffectiveModel(DefaultModelBuilder.java:798)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:896)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:664)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:645)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:167)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:130)
> at
> org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:126)
> at
> org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:110)
> at
> org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:106)
> at
> org.apache.maven.project.ProjectBuilderTest.testLocationTrackingResolution(ProjectBuilderTest.java:357)
> ...
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
> Caused by: java.net.MalformedURLException: Illegal character found in host:
> '{'
> at java.base/java.net.URL.(URL.java:798)
> at java.base/java.net.URL.(URL.java:646)
> at java.base/java.net.URL.(URL.java:582)
> at
> org.apache.maven.repository.TestRepositoryConnector.(TestRepositoryConnector.java:54)
> ... 91 more
> Caused by: java.lang.IllegalArgumentException: Illegal character found in
> host: '{'
> at java.base/java.net.URLStreamHandler.setURL(URLStreamHandler.java:522)
> at
> java.base/java.net.URLStreamHandler.parseURL(URLStreamHandler.java:325)
> at java.base/sun.net.www.protocol.file.Handler.parseURL(Handler.java:56)
> at java.base/java.net.URL.(URL.java:793)
> {code}
>
> This seems to be related to [https://bugs.openjdk.org/browse/JDK-8293590]
> which moved some of the URL validation to the constructor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7743) Make the build work on JDK 20
[
https://issues.apache.org/jira/browse/MNG-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702257#comment-17702257
]
Petr Široký commented on MNG-7743:
--
So the "proper" fix would be to get rid of the property in the repo url?
> Make the build work on JDK 20
> -
>
> Key: MNG-7743
> URL: https://issues.apache.org/jira/browse/MNG-7743
> Project: Maven
> Issue Type: Task
> Components: Bootstrap & Build
>Reporter: Petr Široký
>Priority: Minor
>
> When building Maven (from master and 3.9.x branches) using the latest JDK 20
> RC (which is very likely going to be promoted to GA), I am seeing the
> following test error:
> {code:java}
> [ERROR]
> org.apache.maven.project.ProjectBuilderTest.testLocationTrackingResolution
> Time elapsed: 0.015 s <<< ERROR!
> java.lang.IllegalStateException: java.net.MalformedURLException: Illegal
> character found in host: '{'
> at
> org.apache.maven.repository.TestRepositoryConnector.(TestRepositoryConnector.java:56)
> at
> org.apache.maven.repository.TestRepositoryConnectorFactory.newInstance(TestRepositoryConnectorFactory.java:39)
> at
> org.eclipse.aether.internal.impl.DefaultRepositoryConnectorProvider.newRepositoryConnector(DefaultRepositoryConnectorProvider.java:121)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:515)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:433)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:261)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:242)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:277)
> at
> org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:167)
> at
> org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:214)
> at
> org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:279)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:1517)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:1339)
> at
> org.apache.maven.model.building.DefaultModelBuilder.readEffectiveModel(DefaultModelBuilder.java:798)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:896)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:664)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:645)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:167)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:130)
> at
> org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:126)
> at
> org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:110)
> at
> org.apache.maven.AbstractCoreMavenComponentTestCase.createMavenSession(AbstractCoreMavenComponentTestCase.java:106)
> at
> org.apache.maven.project.ProjectBuilderTest.testLocationTrackingResolution(ProjectBuilderTest.java:357)
> ...
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
> Caused by: java.net.MalformedURLException: Illegal character found in host:
> '{'
> at java.base/java.net.URL.(URL.java:798)
> at java.base/java.net.URL.(URL.java:646)
> at java.base/java.net.URL.(URL.java:582)
> at
> org.apache.maven.repository.TestRepositoryConnector.(TestRepositoryConnector.java:54)
> ... 91 more
> Caused by: java.lang.IllegalArgumentException: Illegal character found in
> host: '{'
> at java.base/java.net.URLStreamHandler.setURL(URLStreamHandler.java:522)
> at
> java.base/java.net.URLStreamHandler.parseURL(URLStreamHandler.java:325)
> at java.base/sun.net.www.protocol.file.Handler.parseURL(Handler.java:56)
> at java.base/java.net.URL.(URL.java:793)
> {code}
>
> This seems to be related to [https://bugs.openjdk.org/browse/JDK-8293590]
> which moved some of the URL validation to the constructor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702559#comment-17702559
]
Christoph Läubrich commented on MNG-7038:
-
I'm not sure why a launcher now has dripped in here, but to summarize:
- there is already a property working for years but not documented anywhere,
and it is even accessible from the maven model
- now it was asked to make this "official" because user find it useful
No one asked for more properties, or better properties or launchers or
jvm.config ;-)
So at the moment the only problem is that if there is no .mvn folder, the
property is undefined, something that can simply be documented and then its all
fine I think, one could think about a new name but even that seems a bit
over-engineered.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17702587#comment-17702587
]
Christoph Läubrich commented on MNG-7038:
-
> I have been thinking for years to write a C based launcher for Maven similar
> to Eclipse, but never found the time.
You probably can use the eclipse one, it just calls a main method and reads the
jvm args from the eclipse.ini so probably it can be adjusted / stripped down
quite easy.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-965) Symbolic links get copied with absolute path
[
https://issues.apache.org/jira/browse/MASSEMBLY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17703113#comment-17703113
]
Václav Haisman commented on MASSEMBLY-965:
--
It is in Central now:
https://repo1.maven.org/maven2/org/codehaus/plexus/plexus-io/3.4.1/
> Symbolic links get copied with absolute path
>
>
> Key: MASSEMBLY-965
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-965
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Marc Guillemot
>Assignee: Guillaume Nodet
>Priority: Major
>
> Copied symbolic links in a `` have an absolute path as target and
> not the one of the original resource.
> Example:
> Source: {{foo -> ../my-file1}}
> Assembly: {{foo ->/home/marc/projects/demo/src/somestuff/myfile1}}
> This is a regression compared to 3.3.0. According to git bisect, the problem
> has been introduced with commit
> [https://github.com/apache/maven-assembly-plugin/commit/937750250bfe06333f92351fa1a19a9cd5e59d28]
> Pull Request with failing integration test follows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-49) Allow caching for pom package projects
Tomáš Mrázek created MBUILDCACHE-49: --- Summary: Allow caching for pom package projects Key: MBUILDCACHE-49 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-49 Project: Maven Build Cache Extension Issue Type: New Feature Affects Versions: 1.0.0 Reporter: Tomáš Mrázek In class `MavenProjectInput` and method `calculateChecksum()` at line `207` is check for pom project and if true, input files are skipped. What was the reason behind ignoring pom projects? I've seen plenty of pom projects with some build logic where caching does make a sense. For example some resource transformations or building external projects via exec-maven-plugin. In those cases both source and target files exist but different packaing other than pom does not make a lot of sense. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-45) Compiled classes are not copied/restored to target, causing higher phase builds to fail
[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706667#comment-17706667
]
Tomáš Mrázek commented on MBUILDCACHE-45:
-
You have to for some reason explicitly configure target subfolders.
{code:java}
classes
generated-sources
maven-status
{code}
Then those subfolders are correctly zipped and stored and restored in cache.
I am on the other hand unable to restore the jar itself to target folder. Maybe
I just don't get the point of the extension.
Anyways I would expect, that input section would specify files to calculate
hash and defaults to include -> src, and output section would specify actual
files to cache and default to include -> target. Include cannot be specified
for the output tho. And attachedOutputs section is inherently defined for
target. Again I would expect this section to convey cacheable artefacts outside
of the target as some special cases. And I would expect, that all outputs would
be cached/zipped for every phase and then properly restored for the highest
phase run.
Attached outputs are always restored no matter the phase.
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
>Reporter: Miguel Ortega
>Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [INFO] Skipping plugin execution (cached): compiler:compile
> [INFO] Skipping plugin execution (cached): resources:testResources
> [INFO] Skipping plugin execution (cached): compiler:testCompile
> [INFO] Skipping plugin execution (cached): surefire:test {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home:
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7670) Upgrade misc dependencies
[ https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708329#comment-17708329 ] Ceki Gülcü commented on MNG-7670: - [~michael-o] Can you please say a little more on the breaking change in logback 1.4 that you are referring to? > Upgrade misc dependencies > - > > Key: MNG-7670 > URL: https://issues.apache.org/jira/browse/MNG-7670 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.2 > > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] com.google.guava:guava .. 30.1-jre -> > 31.1-jre > [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> > 3.12.0 > [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> > 2.7.0 > [INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 -> > 2.1.1 > [INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 -> > 3.5.0 > [INFO] org.hamcrest:hamcrest-core 1.3 -> > 2.2 > [INFO] org.hamcrest:hamcrest-library . 1.3 -> > 2.2 > [INFO] org.mockito:mockito-core 2.21.0 -> > 4.11.0 > [INFO] org.powermock:powermock-reflect ... 1.7.4 -> > 2.0.9 > [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> > 2.9.1 > [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> > 2.9.1 > Logback 1.3.x depends on SLF4J 2.x, Logback 1.4.x requires Java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7670) Upgrade misc dependencies
[ https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708329#comment-17708329 ] Ceki Gülcü edited comment on MNG-7670 at 4/4/23 9:23 AM: - [~michael-o] Can you please say a little more on the breaking change in logback 1.4 that you are referring to? Is it the JDK 11 dependency? was (Author: c...@qos.ch): [~michael-o] Can you please say a little more on the breaking change in logback 1.4 that you are referring to? > Upgrade misc dependencies > - > > Key: MNG-7670 > URL: https://issues.apache.org/jira/browse/MNG-7670 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.2 > > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] com.google.guava:guava .. 30.1-jre -> > 31.1-jre > [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> > 3.12.0 > [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> > 2.7.0 > [INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 -> > 2.1.1 > [INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 -> > 3.5.0 > [INFO] org.hamcrest:hamcrest-core 1.3 -> > 2.2 > [INFO] org.hamcrest:hamcrest-library . 1.3 -> > 2.2 > [INFO] org.mockito:mockito-core 2.21.0 -> > 4.11.0 > [INFO] org.powermock:powermock-reflect ... 1.7.4 -> > 2.0.9 > [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> > 2.9.1 > [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> > 2.9.1 > Logback 1.3.x depends on SLF4J 2.x, Logback 1.4.x requires Java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7670) Upgrade misc dependencies
[ https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708333#comment-17708333 ] Ceki Gülcü commented on MNG-7670: - Thank you for clarifying. You are aware that the 1.3.x branch deals exactly this issue? The 1.4.x and 1.3.x have identical code except that the former targets jakarta.* namespace whereas the latter targets the javax.* namespace. Is using the logback 1.3 branch not an option? > Upgrade misc dependencies > - > > Key: MNG-7670 > URL: https://issues.apache.org/jira/browse/MNG-7670 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.2 > > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] com.google.guava:guava .. 30.1-jre -> > 31.1-jre > [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> > 3.12.0 > [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> > 2.7.0 > [INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 -> > 2.1.1 > [INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 -> > 3.5.0 > [INFO] org.hamcrest:hamcrest-core 1.3 -> > 2.2 > [INFO] org.hamcrest:hamcrest-library . 1.3 -> > 2.2 > [INFO] org.mockito:mockito-core 2.21.0 -> > 4.11.0 > [INFO] org.powermock:powermock-reflect ... 1.7.4 -> > 2.0.9 > [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> > 2.9.1 > [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> > 2.9.1 > Logback 1.3.x depends on SLF4J 2.x, Logback 1.4.x requires Java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7670) Upgrade misc dependencies
[ https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708333#comment-17708333 ] Ceki Gülcü edited comment on MNG-7670 at 4/4/23 9:44 AM: - [~michael-o] Thank you for clarifying. You are aware that the 1.3.x branch deals exactly this issue? The 1.4.x and 1.3.x have identical code except that the former targets jakarta.* namespace whereas the latter targets the javax.* namespace. Is using the logback 1.3 branch not an option? was (Author: c...@qos.ch): Thank you for clarifying. You are aware that the 1.3.x branch deals exactly this issue? The 1.4.x and 1.3.x have identical code except that the former targets jakarta.* namespace whereas the latter targets the javax.* namespace. Is using the logback 1.3 branch not an option? > Upgrade misc dependencies > - > > Key: MNG-7670 > URL: https://issues.apache.org/jira/browse/MNG-7670 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.2 > > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] com.google.guava:guava .. 30.1-jre -> > 31.1-jre > [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> > 3.12.0 > [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> > 2.7.0 > [INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 -> > 2.1.1 > [INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 -> > 3.5.0 > [INFO] org.hamcrest:hamcrest-core 1.3 -> > 2.2 > [INFO] org.hamcrest:hamcrest-library . 1.3 -> > 2.2 > [INFO] org.mockito:mockito-core 2.21.0 -> > 4.11.0 > [INFO] org.powermock:powermock-reflect ... 1.7.4 -> > 2.0.9 > [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> > 2.9.1 > [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> > 2.9.1 > Logback 1.3.x depends on SLF4J 2.x, Logback 1.4.x requires Java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7670) Upgrade misc dependencies
[ https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708333#comment-17708333 ] Ceki Gülcü edited comment on MNG-7670 at 4/4/23 9:47 AM: - [~michael-o] Thank you for clarifying. You are aware that the 1.3.x branch deals exactly this issue? The 1.4.x and 1.3.x have identical code except that the former targets jakarta.* namespace whereas the latter targets the javax.* namespace. If you are targeting the javax.* namespace, you could opt to use the logback 1.3 branch or is that not an option? was (Author: c...@qos.ch): [~michael-o] Thank you for clarifying. You are aware that the 1.3.x branch deals exactly this issue? The 1.4.x and 1.3.x have identical code except that the former targets jakarta.* namespace whereas the latter targets the javax.* namespace. Is using the logback 1.3 branch not an option? > Upgrade misc dependencies > - > > Key: MNG-7670 > URL: https://issues.apache.org/jira/browse/MNG-7670 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.2 > > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] com.google.guava:guava .. 30.1-jre -> > 31.1-jre > [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> > 3.12.0 > [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> > 2.7.0 > [INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 -> > 2.1.1 > [INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 -> > 3.5.0 > [INFO] org.hamcrest:hamcrest-core 1.3 -> > 2.2 > [INFO] org.hamcrest:hamcrest-library . 1.3 -> > 2.2 > [INFO] org.mockito:mockito-core 2.21.0 -> > 4.11.0 > [INFO] org.powermock:powermock-reflect ... 1.7.4 -> > 2.0.9 > [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> > 2.9.1 > [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> > 2.9.1 > Logback 1.3.x depends on SLF4J 2.x, Logback 1.4.x requires Java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7755) If a plugin is an extension, the managed version is ignored
Christoph Läubrich created MNG-7755:
---
Summary: If a plugin is an extension, the managed version is
ignored
Key: MNG-7755
URL: https://issues.apache.org/jira/browse/MNG-7755
Project: Maven
Issue Type: Bug
Reporter: Christoph Läubrich
I have the following in a child pom:
{code}
org.eclipse.tycho
tycho-bnd-plugin
${tycho.version}
true
{code}
and in the parent:
{code}
org.eclipse.tycho
tycho-bnd-plugin
${tycho.version}
{code}
This gives an warning (and alter an error):
[WARNING] 'build.plugins.plugin.version' for org.eclipse.tycho:tycho-bnd-plugin
is missing.
If I write directly in the child
{code}
org.eclipse.tycho
tycho-bnd-plugin
${tycho.version}
true
{code}
it works ... it seems to be triggered by the true tag
here that it then do not look at ate managed version...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7670) Upgrade misc dependencies
[ https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708333#comment-17708333 ] Ceki Gülcü edited comment on MNG-7670 at 4/5/23 9:12 AM: - [~michael-o] Thank you for clarifying. You are aware that the 1.3.x branch deals exactly with this issue? The 1.4.x and 1.3.x have identical code except that the former targets jakarta.* namespace whereas the latter targets the javax.* namespace. If you are targeting the javax.* namespace, you could opt to use the logback 1.3 branch or is that not an option? was (Author: c...@qos.ch): [~michael-o] Thank you for clarifying. You are aware that the 1.3.x branch deals exactly this issue? The 1.4.x and 1.3.x have identical code except that the former targets jakarta.* namespace whereas the latter targets the javax.* namespace. If you are targeting the javax.* namespace, you could opt to use the logback 1.3 branch or is that not an option? > Upgrade misc dependencies > - > > Key: MNG-7670 > URL: https://issues.apache.org/jira/browse/MNG-7670 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.2 > > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] com.google.guava:guava .. 30.1-jre -> > 31.1-jre > [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> > 3.12.0 > [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> > 2.7.0 > [INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 -> > 2.1.1 > [INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 -> > 3.5.0 > [INFO] org.hamcrest:hamcrest-core 1.3 -> > 2.2 > [INFO] org.hamcrest:hamcrest-library . 1.3 -> > 2.2 > [INFO] org.mockito:mockito-core 2.21.0 -> > 4.11.0 > [INFO] org.powermock:powermock-reflect ... 1.7.4 -> > 2.0.9 > [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> > 2.9.1 > [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> > 2.9.1 > Logback 1.3.x depends on SLF4J 2.x, Logback 1.4.x requires Java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7670) Upgrade misc dependencies
[ https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17708770#comment-17708770 ] Ceki Gülcü commented on MNG-7670: - [~michael-o] I was under the impression that by maintaining two versions, logback was providing a service above and beyond. I should add that JMPS/Jigsaw compliance is already proving to be very difficult, doing so for both javax.* and jakarta.* seems quite beyond our means. > We will remain on SLF4J 1.7.x and configurewise Logback 1.3 for now. Given that logback 1.3 requires SLF4J 2.0.x, I fail to understand your statement. > Upgrade misc dependencies > - > > Key: MNG-7670 > URL: https://issues.apache.org/jira/browse/MNG-7670 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.2 > > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] com.google.guava:guava .. 30.1-jre -> > 31.1-jre > [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> > 3.12.0 > [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> > 2.7.0 > [INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 -> > 2.1.1 > [INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 -> > 3.5.0 > [INFO] org.hamcrest:hamcrest-core 1.3 -> > 2.2 > [INFO] org.hamcrest:hamcrest-library . 1.3 -> > 2.2 > [INFO] org.mockito:mockito-core 2.21.0 -> > 4.11.0 > [INFO] org.powermock:powermock-reflect ... 1.7.4 -> > 2.0.9 > [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> > 2.9.1 > [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> > 2.9.1 > Logback 1.3.x depends on SLF4J 2.x, Logback 1.4.x requires Java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSITE-946) I get an error when running mvn site with 4.0.0, when it was working fine with 3.12.1
Emmanuel Lécharny created MSITE-946:
---
Summary: I get an error when running mvn site with 4.0.0, when it
was working fine with 3.12.1
Key: MSITE-946
URL: https://issues.apache.org/jira/browse/MSITE-946
Project: Maven Site Plugin
Issue Type: Bug
Components: site:run
Affects Versions: 4.0.0-M6
Environment: Mac OS X, Java 8
Reporter: Emmanuel Lécharny
Running {{mvn site}} on Apache LDAP API project, I get this error:
{code}
$ mvn site
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256M; support was
removed in 8.0
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Apache Directory LDAP API [pom]
[INFO] Apache Directory LDAP API I18n [bundle]
[INFO] Apache Directory LDAP API Utilities [bundle]
[INFO] Apache Directory API ASN.1 Parent [pom]
[INFO] Apache Directory API ASN.1 API [bundle]
[INFO] Apache Directory API ASN.1 BER [bundle]
[INFO] Apache Directory LDAP API Parent [pom]
[INFO] Apache Directory LDAP API Model [bundle]
[INFO] Apache Directory LDAP API Codec Parent [pom]
[INFO] Apache Directory LDAP API Codec Core[bundle]
[INFO] Apache Directory LDAP API Net Parent [pom]
[INFO] Apache Directory LDAP API Network MINA [bundle]
[INFO] Apache Directory LDAP API Extras Parent[pom]
[INFO] Apache Directory LDAP API Extras Codec API [bundle]
[INFO] Apache Directory LDAP API Extras Codec [bundle]
[INFO] Apache Directory LDAP API Codec Standalone [jar]
[INFO] Apache Directory LDAP API DSML Parent [pom]
[INFO] Apache Directory LDAP API DSML Parser [bundle]
[INFO] Apache Directory LDAP API Extras ACI[bundle]
[INFO] Apache Directory LDAP API Schema Parent[pom]
[INFO] Apache Directory LDAP API Schema Data [jar]
[INFO] Apache Directory LDAP API Client Parent[pom]
[INFO] Apache Directory LDAP API Client API[bundle]
[INFO] Apache Directory LDAP API DSML Engine [bundle]
[INFO] Apache Directory LDAP API Extras Util [bundle]
[INFO] Apache Directory LDAP API Extras Stored Procedures [bundle]
[INFO] Apache Directory LDAP API Extras Trigger[bundle]
[INFO] Apache Directory LDAP API Schema Converter [bundle]
[INFO] Apache Directory API All [jar]
[INFO] Apache Directory LDAP API Client All [jar]
[INFO] Apache Directory API Integration Tests [jar]
[INFO] Apache Directory API OSGi Integration Tests[jar]
[INFO] Apache Directory LDAP API Distribution [pom]
[INFO]
[INFO] < org.apache.directory.api:api-parent >-
[INFO] Building Apache Directory LDAP API 2.1.4-SNAPSHOT [1/33]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-site-plugin:4.0.0-M6:site (default-site) @ api-parent ---
[WARNING] Error initializing:
org.codehaus.plexus.velocity.DefaultVelocityComponent@1b495d4
java.lang.NoSuchMethodError:
org.apache.velocity.app.VelocityEngine.setProperties(Ljava/util/Properties;)V
at org.codehaus.plexus.velocity.DefaultVelocityComponent.initialize
(DefaultVelocityComponent.java:65)
at org.eclipse.sisu.plexus.PlexusLifecycleManager.initialize
(PlexusLifecycleManager.java:303)
at org.eclipse.sisu.plexus.PlexusLifecycleManager.activate
(PlexusLifecycleManager.java:207)
at org.eclipse.sisu.bean.BeanScheduler.schedule (BeanScheduler.java:151)
at org.eclipse.sisu.plexus.PlexusLifecycleManager.manage
(PlexusLifecycleManager.java:147)
at org.eclipse.sisu.plexus.PlexusBeanBinder.afterInjection
(PlexusBeanBinder.java:72)
at com.google.inject.internal.MembersInjectorImpl.notifyListeners
(MembersInjectorImpl.java:131)
at com.google.inject.internal.ConstructorInjector.provision
(ConstructorInjector.java:125)
at com.google.inject.internal.ConstructorInjector.access$000
(ConstructorInjector.java:32)
at com.google.inject.internal.ConstructorInjector$1.call
(ConstructorInjector.java:98)
[jira] [Commented] (MSITE-946) I get an error when running mvn site with 4.0.0, when it was working fine with 3.12.1
[
https://issues.apache.org/jira/browse/MSITE-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710050#comment-17710050
]
Emmanuel Lécharny commented on MSITE-946:
-
Thanks a lot for the clues! Will get that fixed on our side :)
> I get an error when running mvn site with 4.0.0, when it was working fine
> with 3.12.1
> -
>
> Key: MSITE-946
> URL: https://issues.apache.org/jira/browse/MSITE-946
> Project: Maven Site Plugin
> Issue Type: Bug
>Affects Versions: 4.0.0-M6
> Environment: Mac OS X, Java 8
>Reporter: Emmanuel Lécharny
>Assignee: Michael Osipov
>Priority: Major
>
> Running {{mvn site}} on Apache LDAP API project, I get this error:
> {code}
> $ mvn site
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256M; support
> was removed in 8.0
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache Directory LDAP API
> [pom]
> [INFO] Apache Directory LDAP API I18n
> [bundle]
> [INFO] Apache Directory LDAP API Utilities
> [bundle]
> [INFO] Apache Directory API ASN.1 Parent
> [pom]
> [INFO] Apache Directory API ASN.1 API
> [bundle]
> [INFO] Apache Directory API ASN.1 BER
> [bundle]
> [INFO] Apache Directory LDAP API Parent
> [pom]
> [INFO] Apache Directory LDAP API Model
> [bundle]
> [INFO] Apache Directory LDAP API Codec Parent
> [pom]
> [INFO] Apache Directory LDAP API Codec Core
> [bundle]
> [INFO] Apache Directory LDAP API Net Parent
> [pom]
> [INFO] Apache Directory LDAP API Network MINA
> [bundle]
> [INFO] Apache Directory LDAP API Extras Parent
> [pom]
> [INFO] Apache Directory LDAP API Extras Codec API
> [bundle]
> [INFO] Apache Directory LDAP API Extras Codec
> [bundle]
> [INFO] Apache Directory LDAP API Codec Standalone
> [jar]
> [INFO] Apache Directory LDAP API DSML Parent
> [pom]
> [INFO] Apache Directory LDAP API DSML Parser
> [bundle]
> [INFO] Apache Directory LDAP API Extras ACI
> [bundle]
> [INFO] Apache Directory LDAP API Schema Parent
> [pom]
> [INFO] Apache Directory LDAP API Schema Data
> [jar]
> [INFO] Apache Directory LDAP API Client Parent
> [pom]
> [INFO] Apache Directory LDAP API Client API
> [bundle]
> [INFO] Apache Directory LDAP API DSML Engine
> [bundle]
> [INFO] Apache Directory LDAP API Extras Util
> [bundle]
> [INFO] Apache Directory LDAP API Extras Stored Procedures
> [bundle]
> [INFO] Apache Directory LDAP API Extras Trigger
> [bundle]
> [INFO] Apache Directory LDAP API Schema Converter
> [bundle]
> [INFO] Apache Directory API All
> [jar]
> [INFO] Apache Directory LDAP API Client All
> [jar]
> [INFO] Apache Directory API Integration Tests
> [jar]
> [INFO] Apache Directory API OSGi Integration Tests
> [jar]
> [INFO] Apache Directory LDAP API Distribution
> [pom]
> [INFO]
> [INFO] < org.apache.directory.api:api-parent
> >-
> [INFO] Building Apache Directory LDAP API 2.1.4-SNAPSHOT
> [1/33]
> [INFO] [ pom
> ]-
> [INFO]
> [INFO] --- maven-site-plugin:4.0.0-M6:site (default-site) @ api-parent ---
> [WARNING] Error initializing:
> org.codehaus.plexus.velocity.DefaultVelocityComponent@1b495d4
> java.lang.NoSuchMethodError:
> org.apache.velocity.app.VelocityEngine.setProperties(Ljava/util/Properties;)V
> at org.codehaus.plexus.velocity.DefaultVelocityComponent.initialize
> (De
[jira] [Commented] (MNG-7670) Upgrade misc dependencies
[ https://issues.apache.org/jira/browse/MNG-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711717#comment-17711717 ] Ceki Gülcü commented on MNG-7670: - [~michael-o] I think you are right about splitting various dependencies into separate logback modules. It would have been a wiser choice, a choice that shall be adopted resources permitting. I should add that the task is probably harder than it sounds as logback-access is very tightly coupled with the servlet api. > Upgrade misc dependencies > - > > Key: MNG-7670 > URL: https://issues.apache.org/jira/browse/MNG-7670 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.2 > > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] com.google.guava:guava .. 30.1-jre -> > 31.1-jre > [INFO] org.apache.commons:commons-lang3 . 3.8.1 -> > 3.12.0 > [INFO] org.codehaus.plexus:plexus-classworlds 2.6.0 -> > 2.7.0 > [INFO] org.codehaus.plexus:plexus-component-annotations .. 2.1.0 -> > 2.1.1 > [INFO] org.codehaus.plexus:plexus-utils .. 3.4.2 -> > 3.5.0 > [INFO] org.hamcrest:hamcrest-core 1.3 -> > 2.2 > [INFO] org.hamcrest:hamcrest-library . 1.3 -> > 2.2 > [INFO] org.mockito:mockito-core 2.21.0 -> > 4.11.0 > [INFO] org.powermock:powermock-reflect ... 1.7.4 -> > 2.0.9 > [INFO] org.xmlunit:xmlunit-core .. 2.2.1 -> > 2.9.1 > [INFO] org.xmlunit:xmlunit-matchers .. 2.2.1 -> > 2.9.1 > Logback 1.3.x depends on SLF4J 2.x, Logback 1.4.x requires Java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17651875#comment-17651875
]
Petr Široký commented on MNG-7631:
--
I did a bit more digging into the changes from
[https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
and I _believe_ I found the reason for the changed behavior.
The user settings and global settings and being merged at some point, using the
{{MavenSettingsMerger}} -
[https://github.com/apache/maven/blob/maven-4.0.0-alpha-3/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L71|https://github.com/apache/maven/blob/maven-4.0.0-alpha-3/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L71.].
The code for {{localRepository}} merge specifically checks if the user value
is either {{null}} or empty string (via {{{}StringUtils.isEmpty(){}}})and if it
is, it replaces it with the global value (which is {{null}} by default). So at
this point, the empty string gets replaced by {{{}null{}}}. This could be
called a bug / inconsistent behavior by itself (as [~michael-o] pointed out
above). However, this actually has not changed between Maven 3.x and 4.x – the
behavior is the same.
What changed is the way the user and global {{Settings}} objects are getting
merged. Since Maven 4.x uses immutable {{Settings}} class, the code changed
quite a bit – from just calling {{settings.setLocalRepository()}} in Maven
3.8.x
([https://github.com/apache/maven/blob/maven-3.8.6/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L95|https://github.com/apache/maven/blob/maven-3.8.6/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L95).])
to using a builder and creating a new instance of {{Settings}} class if needed
(e.g. if things actually changed). The "problem" here is that the builder does
not really differentiate between the default {{null}} value for
{{localRepository}} and one that has been set explicitly
([https://github.com/apache/maven/blob/maven-4.0.0-alpha-3/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L74|https://github.com/apache/maven/blob/maven-4.0.0-alpha-3/maven-settings-builder/src/main/java/org/apache/maven/settings/merge/MavenSettingsMerger.java#L74).]).
This results in the {{localRepository}} being empty string after the merge
(since that's the original value from user settings and is not replaced by
{{null}} coming from global settings).
>From the above discussion I am still not sure if the preferred solution is to
>somehow revert the new behavior (which could be considered a bug fix), or just
>document that Maven 4.x behaves differently for this edge case. The "fix"
>would probably need to happen in the merger class, as it would need to somehow
>differentiate between the default {{null}} and one that is being set
>explicitly.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd";>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in M
[jira] [Created] (MENFORCER-448) Upgrade parent to version 39
Petr Široký created MENFORCER-448:
-
Summary: Upgrade parent to version 39
Key: MENFORCER-448
URL: https://issues.apache.org/jira/browse/MENFORCER-448
Project: Maven Enforcer Plugin
Issue Type: Dependency upgrade
Reporter: Petr Široký
There is a new version of {{maven-parent}} – 39.
It contains additional minor changes to the code style, so reformatting will be
needed (but should really just be small changes in the order of import
statements).
See
[https://github.com/apache/maven-parent/compare/maven-parent-38...maven-parent-39]
for the list of changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-378) requireReleaseDeps does not support optional dependencies or runtime scope
[
https://issues.apache.org/jira/browse/MENFORCER-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652320#comment-17652320
]
Petr Široký commented on MENFORCER-378:
---
I tried to run the test project with plugin version {{3.1.0}} and that seems to
work as I would expect:
{code:java}
$ /tmp/test ❯ mvn validate
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Homeserver Domains [pom]
[INFO] Domeinen [pom]
[INFO] Common Libraries [jar]
[INFO] Common Libs [jar]
[INFO]
[INFO] < nl.mytest:homeserver >
[INFO] Building Homeserver Domains 0.0.1-SNAPSHOT [1/4]
[INFO] [ pom ]-
[INFO]
[INFO] -< nl.mytest:domains >--
[INFO] Building Domeinen 0.0.1-SNAPSHOT [2/4]
[INFO] [ pom ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.1.0:enforce (enforce) @ domains ---
[INFO]
[INFO] ---< nl.mytest:domain_libs >
[INFO] Building Common Libraries 0.0.1-SNAPSHOT [3/4]
[INFO] [ jar ]-
[WARNING] The POM for
nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT is missing, no
dependency information available
[INFO]
[INFO] --- maven-enforcer-plugin:3.1.0:enforce (enforce) @ domain_libs ---
[ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireReleaseDeps failed
with message:
Found Banned Dependency:
nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT
Use 'mvn dependency:tree' to locate the source of the banned dependencies.
[INFO]
[INFO] Reactor Summary for Homeserver Domains 0.0.1-SNAPSHOT:
[INFO]
[INFO] Homeserver Domains . SUCCESS [ 0.001 s]
[INFO] Domeinen ... SUCCESS [ 0.195 s]
[INFO] Common Libraries ... FAILURE [ 0.005 s]
[INFO] Common Libs SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.247 s
[INFO] Finished at: 2022-12-27T23:36:28+01:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.1.0:enforce (enforce) on
project domain_libs: Some Enforcer rules have failed. Look above for specific
messages explaining why the rule failed. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :domain_libs {code}
There is a WARN about missing pom for that dependency, which seems OK. The
enforcer rule also fails because the dependency is in fact a SNAPSHOT. I would
say the rule should not really care if the dependency is optional or not. If
it's a SNAPSHOT then I would expect a failure.
I am aware that this issue is almost 2 years old, but I figured I would try to
double-check if this is has been already fixed or not and if yes, then we
should close it and clean-up the backlog a bit.
> requireReleaseDeps does not support optional dependencies or runtime scope
> --
>
> Key: MENFORCER-378
> URL: https://issues.apache.org/jira/browse/MENFORCER-378
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M3
> Environme
[jira] [Commented] (MENFORCER-378) requireReleaseDeps does not support optional dependencies or runtime scope
[
https://issues.apache.org/jira/browse/MENFORCER-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652326#comment-17652326
]
Petr Široký commented on MENFORCER-378:
---
{{3.2.0-SNAPSHOT}} seems to behave the same, with the added benefit of snicer
error message:
{code:java}
[INFO] ---< nl.mytest:domain_libs >
[INFO] Building Common Libraries 0.0.1-SNAPSHOT [3/4]
[INFO] [ jar ]-
[WARNING] The POM for
nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT is missing, no
dependency information available
[INFO]
[INFO] --- maven-enforcer-plugin:3.2.0-SNAPSHOT:enforce (enforce) @ domain_libs
---
[INFO] Executing rule: org.apache.maven.plugins.enforcer.RequireReleaseDeps
[INFO] Executing rule: org.apache.maven.plugins.enforcer.RequireSameVersions
[ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireReleaseDeps failed
with message:
nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT <--- is not a
release dependency
[INFO]
[INFO] Reactor Summary for Homeserver Domains 0.0.1-SNAPSHOT:
[INFO]
[INFO] Homeserver Domains . SUCCESS [ 0.001 s]
[INFO] Domeinen ... SUCCESS [ 0.138 s]
[INFO] Common Libraries ... FAILURE [ 0.010 s]
[INFO] Common Libs SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.192 s
[INFO] Finished at: 2022-12-28T00:12:36+01:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.2.0-SNAPSHOT:enforce (enforce)
on project domain_libs: Some Enforcer rules have failed. Look above for
specific messages explaining why the rule failed. -> [Help 1]{code}
> requireReleaseDeps does not support optional dependencies or runtime scope
> --
>
> Key: MENFORCER-378
> URL: https://issues.apache.org/jira/browse/MENFORCER-378
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M3
> Environment: Windows
>Reporter: Casper Roubos
>Priority: Major
> Attachments: test.zip
>
>
> With using the the enforcer throws a RuntimeException
> due to the following error:
> {code}
> Caused by:
> org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException:
> Could not resolve following dependencies:
> [nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT (runtime?)]
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies
> (Maven31DependencyGraphBuilder.java:133)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph
> (Maven31DependencyGraphBuilder.java:113)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph
> (DefaultDependencyGraphBuilder.java:91)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph
> (DefaultDependencyGraphBuilder.java:66)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.getDependenciesToCheck
> (AbstractBanDependencies.java:122)
> at org.apache.maven.plugins.enforcer.AbstractBanDependencies.execute
> (AbstractBanDependencies.java:86)
> at org.apache.maven.plugins.enforcer.RequireReleaseDeps.execute
> (RequireReleaseDeps.java:105)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute
> (EnforceMojo.java:205){code}
> This file is an optional dependency and the POM is sometimes not available. I
> have given the optional parameter in the POM
> {code}
>
> nl.myshared.datafiles
> runtime_data
> ${project.version}
> selector
> runtime
> true
>
> {code}
> I report this as a bug, since the parameter is long supported in
> maven.
> In my opinion "AbstractBanDependencies.getDependenciesToCheck" line 139
> should have a 'if present and if optional' check. If so, no RuntimeException
> should be thrown
[jira] [Comment Edited] (MENFORCER-378) requireReleaseDeps does not support optional dependencies or runtime scope
[
https://issues.apache.org/jira/browse/MENFORCER-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652326#comment-17652326
]
Petr Široký edited comment on MENFORCER-378 at 12/27/22 11:15 PM:
--
{{3.2.0-SNAPSHOT}} seems to behave the same, with the added benefit of nicer
error message:
{code:java}
[INFO] ---< nl.mytest:domain_libs >
[INFO] Building Common Libraries 0.0.1-SNAPSHOT [3/4]
[INFO] [ jar ]-
[WARNING] The POM for
nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT is missing, no
dependency information available
[INFO]
[INFO] --- maven-enforcer-plugin:3.2.0-SNAPSHOT:enforce (enforce) @ domain_libs
---
[INFO] Executing rule: org.apache.maven.plugins.enforcer.RequireReleaseDeps
[INFO] Executing rule: org.apache.maven.plugins.enforcer.RequireSameVersions
[ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireReleaseDeps failed
with message:
nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT <--- is not a
release dependency
[INFO]
[INFO] Reactor Summary for Homeserver Domains 0.0.1-SNAPSHOT:
[INFO]
[INFO] Homeserver Domains . SUCCESS [ 0.001 s]
[INFO] Domeinen ... SUCCESS [ 0.138 s]
[INFO] Common Libraries ... FAILURE [ 0.010 s]
[INFO] Common Libs SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.192 s
[INFO] Finished at: 2022-12-28T00:12:36+01:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.2.0-SNAPSHOT:enforce (enforce)
on project domain_libs: Some Enforcer rules have failed. Look above for
specific messages explaining why the rule failed. -> [Help 1]{code}
was (Author: psiroky):
{{3.2.0-SNAPSHOT}} seems to behave the same, with the added benefit of snicer
error message:
{code:java}
[INFO] ---< nl.mytest:domain_libs >
[INFO] Building Common Libraries 0.0.1-SNAPSHOT [3/4]
[INFO] [ jar ]-
[WARNING] The POM for
nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT is missing, no
dependency information available
[INFO]
[INFO] --- maven-enforcer-plugin:3.2.0-SNAPSHOT:enforce (enforce) @ domain_libs
---
[INFO] Executing rule: org.apache.maven.plugins.enforcer.RequireReleaseDeps
[INFO] Executing rule: org.apache.maven.plugins.enforcer.RequireSameVersions
[ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireReleaseDeps failed
with message:
nl.myshared.datafiles:runtime_data:selector:0.0.1-SNAPSHOT <--- is not a
release dependency
[INFO]
[INFO] Reactor Summary for Homeserver Domains 0.0.1-SNAPSHOT:
[INFO]
[INFO] Homeserver Domains . SUCCESS [ 0.001 s]
[INFO] Domeinen ... SUCCESS [ 0.138 s]
[INFO] Common Libraries ... FAILURE [ 0.010 s]
[INFO] Common Libs SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.192 s
[INFO] Finished at: 2022-12-28T00:12:36+01:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.2.0-SNAPSHOT:enforce (enforce)
on project domain_libs: Some Enforcer rules have failed. Look above for
specific messages explaining why the rule failed. -> [Help 1]{code}
> requireReleaseDeps does not support optional dependencies or runtime scope
> --
>
> Key: MENFORCER-378
> URL: https://issues.apache.org/jira/browse/MENFORCER-378
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M3
> Environment: Windows
>Reporter: Casper Roubos
>Priority: Major
> Attachments: test.zip
>
>
> With using the the enforcer throws a RuntimeException
> due to the following error:
> {code}
> Caused by:
> org.ap
[jira] [Commented] (MENFORCER-434) Version 3.1.0 is not enforcing bannedDependencies rules
[
https://issues.apache.org/jira/browse/MENFORCER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652844#comment-17652844
]
Petr Široký commented on MENFORCER-434:
---
Yes, I just tested with latest {{3.2.0-SNAPSHOT}} and the execution fails with:
{code:java}
$ mvn validate -f pom-not-enforced.xml # after changing the plugin version to
3.2.0-SNAPSHOT
[INFO] Scanning for projects...
[INFO]
[INFO] --< maven.sample.issue:MENFORCER-434 >--
[INFO] Building MENFORCER-434 1.0.0-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-enforcer-plugin:3.2.0-SNAPSHOT:enforce (enforce-versions) @
MENFORCER-434 ---
[INFO] Executing rule: org.apache.maven.plugins.enforcer.BannedPlugins
[INFO] Executing rule: org.apache.maven.plugins.enforcer.BannedDependencies
[INFO] Executing rule: org.apache.maven.plugins.enforcer.RequireMavenVersion
[INFO] Executing rule: org.apache.maven.plugins.enforcer.RequireJavaVersion
[ERROR] Rule 1: org.apache.maven.plugins.enforcer.BannedDependencies failed
with message:
maven.sample.issue:MENFORCER-434:jar:1.0.0-SNAPSHOT
org.apache.logging.log4j:log4j-core:jar:2.19.0 <--- banned via the
exclude/include list
org.apache.logging.log4j:log4j-api:jar:2.19.0 <--- banned via the
exclude/include list
org.apache.logging.log4j:log4j-slf4j-impl:jar:2.19.0 <--- banned via the
exclude/include list
org.apache.logging.log4j:log4j-jul:jar:2.19.0 <--- banned via the
exclude/include list
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.166 s
[INFO] Finished at: 2022-12-29T14:08:15+01:00{code}
I think we could close this as done? Or do we want to perhaps wait until 3.2.0
is released?
> Version 3.1.0 is not enforcing bannedDependencies rules
> ---
>
> Key: MENFORCER-434
> URL: https://issues.apache.org/jira/browse/MENFORCER-434
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Chris
>Priority: Major
> Fix For: 3.2.0
>
> Attachments: pom-enforced.xml, pom-not-enforced.xml
>
>
> I've been testing rules regarding log4j and have found that the
> {{bannedDependencies}} behave differently between version 3.0.0 and 3.1.0
> My relevant section where I'm purposely creating a failure case by banning
> log4j2 versions less than "3", as well as any log4j 1.x
> NOTE: the following configuration is using version 3.0.0 of
> maven-enforcer-plugin
> {code:java}
>
>
> org.apache.maven.plugins
> maven-enforcer-plugin
> 3.0.0
>
>
> enforce-versions
>
> enforce
>
>
> true
>
>
>
> WARN
>
>
> org.apache.maven.plugins:maven-verifier-plugin
>
> Please consider using the maven-invoker-plugin
> (http://maven.apache.org/plugins/maven-invoker-plugin/)!
>
>
> true
>
>
> org.apache.logging.log4j:*:(,3)
> log4j:log4j
>
>
>
> 3.8.2
>
>
> 1.8.0-202
>
>
>
>
>
>
> {code}
> This results in a positive failure:
> {code:java}
> [INFO] --- maven-enforcer-plugin:3.0.0:enforce (enforce-versions) @
> xxx-x-xxx ---
> [WARNING] Rule 1: org.apache.maven.plugins.enforcer.BannedDependencies failed
> with message:
> Found Banned Dependency: org.apache.logging.log4j:log4j-core:jar:2.19.0
> Found Banned Dependency: org.apache.logging.log4j:log4j-jul:jar:2.19.0
> Found Banned Dependency: org.apache.logging.log4j:log4j-api:jar:2.19.0
> Found Banned Dependency: log4j:log4j:jar:1.2.17
> Found Banned Dependency: org.apache.logging.log4j:log4j-slf4j-impl:jar:2.19.0
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> ---
[jira] [Commented] (MENFORCER-431) Skip specific rules
[
https://issues.apache.org/jira/browse/MENFORCER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652853#comment-17652853
]
Petr Široký commented on MENFORCER-431:
---
Just to clarify the naming of the property: we decided to use
{{enforcer.skipRules}} (instead of just {{skipRules}} or {{{}rulesSkip{}}})
since all the other properties (except {{{}rules{}}}) do use the {{enforcer.}}
prefix as well. The rule name(s) also need to match the names in the XML
configuration, so {{{}banVulnerableDependencies{}}}, rather than
{{{}BanVulnerableDependencies{}}}.
Sample usage would look like this:
{code:java}
mvn verify
-Denforcer.skipRules=banVulnerableDependencies,noPackageCyclesRule{code}
We also planning to deprecate the {{rules}} property and add a new one called
{{enforcer.rules}} to match the naming convention with other properties.
> Skip specific rules
> ---
>
> Key: MENFORCER-431
> URL: https://issues.apache.org/jira/browse/MENFORCER-431
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 3.1.0
>Reporter: Delany
>Assignee: Slawomir Jaranowski
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.2.0
>
>
> I can select rules like
> {code:java}
> mvn verify -Drules=alwaysPass,alwaysFail {code}
> or skip all rules with
> {code:java}
> mvn verify -Denforcer.skip
> {code}
> But what if I want to skip a single rule?
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies{code}
> Or multiple
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies,NoPackageCyclesRule{code}
> Vulnerabilities could be discovered and published at any time. This would be
> a useful to quickly allow my builds to continue, since I can't always upgrade
> dependencies as they appear.
> I don't want to turn off ALL my enforcer checks and I also dont want to list
> all the checks in the build command.
> Skipping a rule is an exceptional circumstance so I don't want to commit it
> to the pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MENFORCER-431) Skip specific rules
[
https://issues.apache.org/jira/browse/MENFORCER-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652853#comment-17652853
]
Petr Široký edited comment on MENFORCER-431 at 12/29/22 3:05 PM:
-
Just to clarify the naming of the property: we decided to use
{{enforcer.skipRules}} (instead of just {{skipRules}} or {{{}rulesSkip{}}})
since all the other properties (except {{{}rules{}}}) do use the {{enforcer.}}
prefix as well. The rule name(s) also needs to match the names in the XML
configuration, -so {{{}banVulnerableDependencies{}}}, rather than
{{{}BanVulnerableDependencies{}}}.- Turns out, you can use both options for the
rule name in pom.xml - either {{banVulnerableDependencies}} or
{{{}BanVulnerableDependencies{}}}. That being said, the {{enforcer.skipRules}}
will do only exact match at this point
Sample usage would look like this:
{code:java}
mvn verify
-Denforcer.skipRules=banVulnerableDependencies,noPackageCyclesRule{code}
or
{code:java}
mvn verify -Denforcer.skipRules=BanVulnerableDependencies,NoPackageCyclesRule
{code}
Depending on how the rules are named in pom.xml.
We also planning to deprecate the {{rules}} property and add a new one called
{{enforcer.rules}} to match the naming convention with other properties.
was (Author: psiroky):
Just to clarify the naming of the property: we decided to use
{{enforcer.skipRules}} (instead of just {{skipRules}} or {{{}rulesSkip{}}})
since all the other properties (except {{{}rules{}}}) do use the {{enforcer.}}
prefix as well. The rule name(s) also need to match the names in the XML
configuration, so {{{}banVulnerableDependencies{}}}, rather than
{{{}BanVulnerableDependencies{}}}.
Sample usage would look like this:
{code:java}
mvn verify
-Denforcer.skipRules=banVulnerableDependencies,noPackageCyclesRule{code}
We also planning to deprecate the {{rules}} property and add a new one called
{{enforcer.rules}} to match the naming convention with other properties.
> Skip specific rules
> ---
>
> Key: MENFORCER-431
> URL: https://issues.apache.org/jira/browse/MENFORCER-431
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 3.1.0
>Reporter: Delany
>Assignee: Slawomir Jaranowski
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.2.0
>
>
> I can select rules like
> {code:java}
> mvn verify -Drules=alwaysPass,alwaysFail {code}
> or skip all rules with
> {code:java}
> mvn verify -Denforcer.skip
> {code}
> But what if I want to skip a single rule?
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies{code}
> Or multiple
> {code:java}
> mvn verify -DrulesSkip=BanVulnerableDependencies,NoPackageCyclesRule{code}
> Vulnerabilities could be discovered and published at any time. This would be
> a useful to quickly allow my builds to continue, since I can't always upgrade
> dependencies as they appear.
> I don't want to turn off ALL my enforcer checks and I also dont want to list
> all the checks in the build command.
> Skipping a rule is an exceptional circumstance so I don't want to commit it
> to the pom.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-454) Deprecate 'rules' property and introduce 'enforcer.rules' as a replacement
[
https://issues.apache.org/jira/browse/MENFORCER-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Široký updated MENFORCER-454:
--
Description:
The current property {{rules}} is the only one that does not use the
{{{}enforcer.prefix{}}}. We can't really delete it (anytime soon), but we could
deprecate it in favor of newly added {{{}enforcer.rules{}}}. This would make
the name consistent with the rest of the properties.
was:
The current property {{rules}} is the only one that does not use the
{{{}enforcer.prefix{}}}. We can't really delete it (anytime soon), but we could
deprecate it in favor of newly added {{{}enforcer.rules{}}}. This would make
the naming consistent with the rest of the properties.
> Deprecate 'rules' property and introduce 'enforcer.rules' as a replacement
> --
>
> Key: MENFORCER-454
> URL: https://issues.apache.org/jira/browse/MENFORCER-454
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 3.1.0
>Reporter: Petr Široký
>Priority: Minor
>
> The current property {{rules}} is the only one that does not use the
> {{{}enforcer.prefix{}}}. We can't really delete it (anytime soon), but we
> could deprecate it in favor of newly added {{{}enforcer.rules{}}}. This would
> make the name consistent with the rest of the properties.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-454) Deprecate 'rules' property and introduce 'enforcer.rules' as a replacement
Petr Široký created MENFORCER-454:
-
Summary: Deprecate 'rules' property and introduce 'enforcer.rules'
as a replacement
Key: MENFORCER-454
URL: https://issues.apache.org/jira/browse/MENFORCER-454
Project: Maven Enforcer Plugin
Issue Type: Improvement
Components: Plugin
Affects Versions: 3.1.0
Reporter: Petr Široký
The current property {{rules}} is the only one that does not use the
{{{}enforcer.prefix{}}}. We can't really delete it (anytime soon), but we could
deprecate it in favor of newly added {{{}enforcer.rules{}}}. This would make
the naming consistent with the rest of the properties.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-437) DependencyConvergence treats provided dependencies are runtime dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652960#comment-17652960
]
Petr Široký commented on MENFORCER-437:
---
It seems this specific issue is fixed – I tried to build Apache Flink from this
commit
[https://github.com/apache/flink/commit/00a25808dfac69ba8319b9c4dc365e13fd5b87d2]
(which is the one before the workarounds applied - as described in the linked
FLINK-29868), using the current {{3.2.0-SNAPSHOT}} version of the plugin and
the error is gone.
That being said, the Flink build still fails during the
{{DependencyConvergence}} check and I am not sure whether this is a bug in the
enforcer rule or actual violation being reported correctly:
{code:java}
[INFO] --- maven-enforcer-plugin:3.2.0-SNAPSHOT:enforce
(dependency-convergence) @ flink-sql-parser ---
[INFO] Executing rule: org.apache.maven.plugins.enforcer.DependencyConvergence
[WARNING]
Dependency convergence error for org.checkerframework:checker-qual:jar:2.11.1
paths to dependency are:
+-org.apache.flink:flink-sql-parser:jar:1.17-SNAPSHOT
+-org.apache.calcite:calcite-core:jar:1.27.0:compile
+-com.google.guava:guava:jar:29.0-jre:compile
+-org.checkerframework:checker-qual:jar:2.11.1:compile
and
+-org.apache.flink:flink-sql-parser:jar:1.17-SNAPSHOT
+-org.apache.calcite:calcite-core:jar:1.27.0:compile
+-org.checkerframework:checker-qual:jar:3.10.0:compile
[ERROR] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence failed
with message:
Failed while enforcing releasability. See above detailed error message. {code}
The pom.xml
([https://github.com/apache/flink/blob/00a25808dfac69ba8319b9c4dc365e13fd5b87d2/flink-table/flink-sql-parser/pom.xml#L50)]
contains
{code:java}
...
com.google.guava
guava
${guava.version}
provided
org.checkerframework
checker-qual
...{code}
Should the enforcer rule take into consideration the {{provided}} scope and the
exclusion here? (this seems to be what {{3.1.0}} is doing, but I am not sure
whether that's correct).
> DependencyConvergence treats provided dependencies are runtime dependencies
> ---
>
> Key: MENFORCER-437
> URL: https://issues.apache.org/jira/browse/MENFORCER-437
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.1.0
>Reporter: Chesnay Schepler
>Priority: Major
> Fix For: 3.2.0
>
>
> After upgrading from 3.0.0-M1 to 3.1.0 we started getting a dependency
> convergence error for a transitive {{provided}} dependencies on
> {{org.osgi.core}}.
> {code}
> ...
> +-org.xerial.snappy:snappy-java:jar:1.1.8.3:runtime
> +-org.osgi:org.osgi.core:jar:4.3.0:runtime
> ...
> +-org.apache.commons:commons-compress:jar:1.21:runtime
> +-org.osgi:org.osgi.core:jar:6.0.0:runtime
> {code}
> It's strange that is is shown here as a runtime dependency, when both
> snappy-java and commons-compress declare it as a provided dependency.
> In fact osgi doesn't show up in the dependency tree at all.
> Being a transitive provided dependency osgi will never be put on the
> classpath unless we manually put it there, so having to deal with such errors
> isn't ideal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-445) Include Java Home in Message for Java Rule Failures
[
https://issues.apache.org/jira/browse/MENFORCER-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653155#comment-17653155
]
Petr Široký commented on MENFORCER-445:
---
The error messages now look like this (unless there is a custom message
provided with the rule configuration):
{code:java}
[ERROR] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed
with message:
Detected JDK version 11.0.17
(JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.17.0.8-1.fc37.x86_64) is not in
the allowed range 17.
[ERROR] Rule 1: org.apache.maven.plugins.enforcer.RequireJavaVendor failed with
message:
Red Hat, Inc. is not an included Required Java Vendor
(JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.17.0.8-1.fc37.x86_64){code}
> Include Java Home in Message for Java Rule Failures
> ---
>
> Key: MENFORCER-445
> URL: https://issues.apache.org/jira/browse/MENFORCER-445
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Documentation, Standard Rules
>Affects Versions: 3.1.0
> Environment: Maven 3.8.5
>Reporter: Robert Krajewski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Labels: enforcer, messages, up-for-grabs, usability
> Fix For: 3.2.0
>
>
> When Java rules fail, for example, when JDK version or vendor fails, knowing
> exactly which Java implementation caused the problem would be handy,
> especially when it happens in a CI system that might be setting up the Java
> to be used in a roundabout way. Including the Java home in the message should
> be enough.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7657) Existing version not resolved
Gwénaël Ruelland created MNG-7657: - Summary: Existing version not resolved Key: MNG-7657 URL: https://issues.apache.org/jira/browse/MNG-7657 Project: Maven Issue Type: Bug Reporter: Gwénaël Ruelland -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
Actual: error
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> What i did, pom with:
> * property:
> [ 10.1.4 ]
> * dependency
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
>
> Expected: a warning instead of an error telling the version exist but not ref
> in metadata.
> the resolver should try the exact version before calling there are none.
> Actual: error
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
Actual: error
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
Actual: error
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> What i did, pom with:
> * property:
> [ 10.1.4 ]
> * dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> Expected: a warning instead of an error telling the version exist but not ref
> in metadata.
> the resolver should try the exact version before calling there are none.
> Actual: error
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
Actual: error
a possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
Actual: error
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> What i did, pom with:
> * property:
> [ 10.1.4 ]
> * dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> Expected: a warning instead of an error telling the version exist but not ref
> in metadata.
> the resolver should try the exact version before calling there are none.
> Actual: error
> a possible related problem: maven-project-info-reports-plugin relies on
> org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
> see
> https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
Actual: error
a possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml
Actual: error
a possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> What i did, pom with:
> * property:
> [ 10.1.4 ]
> * dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> Expected: a warning instead of an error telling the version exist but not ref
> in metadata.
> the resolver should try the exact version before calling there are none.
> [https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
> Actual: error
> a possible related problem: maven-project-info-reports-plugin relies on
> org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
> see
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml
Actual: error
a possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
Actual: error
a possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> What i did, pom with:
> * property:
> [ 10.1.4 ]
> * dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> Expected: a warning instead of an error telling the version exist but not ref
> in metadata.
> the resolver should try the exact version before calling there are none.
> https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml
> Actual: error
> a possible related problem: maven-project-info-reports-plugin relies on
> org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
> see
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
Actual: error
a possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> What i did, pom with:
> * property:
> [ 10.1.4 ]
> * dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> Expected: a warning instead of an error telling the version exist but not ref
> in metadata.
> the resolver should try the exact version before calling there are none.
> [https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
>
> A possible related problem: maven-project-info-reports-plugin relies on
> org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
> see
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
> Actual: error
> Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
> versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
> 10.1.4 ] within specified range
> at
> org.eclipse.aether.internal.impl.collec
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin 3.4.1 relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin 3.4.1 relies on
org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies on
already dead eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin 3.4.1 relies on
org.apache.maven.shared:maven-dependency-tree which relies on eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin 3.4.1 relies on
org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies on
already dead eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Is it possible to replace aether by maven resolver?
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin 3.4.1 relies on
org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies on
already dead eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
* What i did, pom with:
** property:
[ 10.1.4 ]
** dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
* Expected: a warning instead of an error telling the version exist but not
ref in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
* A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
on org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies
on already dead eclipse aether, see:
**
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
* Is it possible to replace aether by maven resolver?
* Actual: error :
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
was:
What i did, pom with:
* property:
[ 10.1.4 ]
* dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
Expected: a warning instead of an error telling the version exist but not ref
in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
A possible related problem: maven-project-info-reports-plugin 3.4.1 relies on
org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies on
already dead eclipse aether
see
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
[https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
Is it possible to replace aether by maven resolver?
Actual: error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
* What i did, pom with:
** property:
[ 10.1.4 ]
** dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
** running site with deps convergence report
* Expected: a warning instead of an error telling the version exist but not
ref in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
* A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
on org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies
on already dead eclipse aether, see:
**
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
* Is it possible to replace aether by maven resolver?
* Actual: error :
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
was:
* What i did, pom with:
** property:
[ 10.1.4 ]
** dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
* Expected: a warning instead of an error telling the version exist but not
ref in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
* A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
on org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies
on already dead eclipse aether, see:
**
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
* Is it possible to replace aether by maven resolver?
* Actual: error :
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
* What i did, pom with:
** property:
[ 10.1.4 ]
** dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
** running goal site with deps convergence report
* Expected: a warning instead of an error telling the version exist but not
ref in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
* A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
on org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies
on already dead eclipse aether, see:
**
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
* Is it possible to replace aether by maven resolver?
* Actual: error :
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
was:
* What i did, pom with:
** property:
[ 10.1.4 ]
** dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
** running site with deps convergence report
* Expected: a warning instead of an error telling the version exist but not
ref in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
* A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
on org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies
on already dead eclipse aether, see:
**
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
* Is it possible to replace aether by maven resolver?
* Actual: error :
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
[jira] [Commented] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653405#comment-17653405
]
Gwénaël Ruelland commented on MNG-7657:
---
Maven 3.8.6
i'll try with 3.8.7 and without spaces (even though it does not seem to
interfer)
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> * What i did, pom with:
> ** property:
> [ 10.1.4 ]
> ** dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> ** running goal site with deps convergence report
> * Expected: a warning instead of an error telling the version exist but not
> ref in metadata.
> the resolver should try the exact version before calling there are none.
> [https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
> * A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
> on org.apache.maven.shared:maven-dependency-tree which version 3.2 still
> relies on already dead eclipse aether, see:
> **
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> ** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
> * Is it possible to replace aether by maven resolver?
> * Actual: error :
> Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
> versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
> 10.1.4 ] within specified range
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
> (DefaultDependencyCollector.java:652)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:394)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
> (DefaultDependencyCollector.java:254)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
> (DefaultRepositorySystem.java:284)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
> (Maven31DependencyCollectorBuilder.java:136)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
> (DefaultDependencyCollectorBuilder.java:72)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
> (DependencyConvergenceReport.java:905)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
> (DependencyConvergenceReport.java:747)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
> (DependencyConvergenceReport.java:160)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:289)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:226)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653405#comment-17653405
]
Gwénaël Ruelland edited comment on MNG-7657 at 1/1/23 12:42 PM:
Maven 3.8.6
i'll try with 3.8.7 and without spaces (even though it does not seem to
interfere)
was (Author: JIRAUSER283915):
Maven 3.8.6
i'll try with 3.8.7 and without spaces (even though it does not seem to
interfer)
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> * What i did, pom with:
> ** property:
> [ 10.1.4 ]
> ** dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> ** running goal site with deps convergence report
> * Expected: a warning instead of an error telling the version exist but not
> ref in metadata.
> the resolver should try the exact version before calling there are none.
> [https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
> * A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
> on org.apache.maven.shared:maven-dependency-tree which version 3.2 still
> relies on already dead eclipse aether, see:
> **
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> ** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
> * Is it possible to replace aether by maven resolver?
> * Actual: error :
> Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
> versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
> 10.1.4 ] within specified range
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
> (DefaultDependencyCollector.java:652)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:394)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
> (DefaultDependencyCollector.java:254)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
> (DefaultRepositorySystem.java:284)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
> (Maven31DependencyCollectorBuilder.java:136)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
> (DefaultDependencyCollectorBuilder.java:72)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
> (DependencyConvergenceReport.java:905)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
> (DependencyConvergenceReport.java:747)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
> (DependencyConvergenceReport.java:160)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:289)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:226)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653407#comment-17653407
]
Gwénaël Ruelland commented on MNG-7657:
---
same error
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for
org.apache.tomcat.embed:tomcat-embed-websocket:jar:[10.1.4] within specified
range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> * What i did, pom with:
> ** property:
> [ 10.1.4 ]
> ** dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> ** running goal site with deps convergence report
> * Expected: a warning instead of an error telling the version exist but not
> ref in metadata.
> the resolver should try the exact version before calling there are none.
> [https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
> * A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
> on org.apache.maven.shared:maven-dependency-tree which version 3.2 still
> relies on already dead eclipse aether, see:
> **
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> ** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
> * Is it possible to replace aether by maven resolver?
> * Actual: error :
> Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
> versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
> 10.1.4 ] within specified range
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
> (DefaultDependencyCollector.java:652)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:394)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
> (DefaultDependencyCollector.java:254)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
> (DefaultRepositorySystem.java:284)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
> (Maven31DependencyCollectorBuilder.java:136)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
> (DefaultDependencyCollectorBuilder.java:72)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
> (Dependen
[jira] [Updated] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gwénaël Ruelland updated MNG-7657:
--
Description:
* What i did, pom with:
** property:
[ 10.1.4 ]
** dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
** running goal site with deps convergence report
* Expected: a warning instead of an error telling the version exist but not
ref in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
* A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
on org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies
on already dead eclipse aether, see:
**
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
* Is it possible to replace aether by maven resolver?
* Actual: error :
{noformat}
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
(Maven31DependencyCollectorBuilder.java:136)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
(DefaultDependencyCollectorBuilder.java:72)
at org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
(DependencyConvergenceReport.java:905)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
(DependencyConvergenceReport.java:747)
at
org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
(DependencyConvergenceReport.java:160)
at org.apache.maven.reporting.AbstractMavenReport.generate
(AbstractMavenReport.java:289)
at
org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
(ReportDocumentRenderer.java:226)
{noformat}
was:
* What i did, pom with:
** property:
[ 10.1.4 ]
** dependency:
org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
** running goal site with deps convergence report
* Expected: a warning instead of an error telling the version exist but not
ref in metadata.
the resolver should try the exact version before calling there are none.
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
* A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
on org.apache.maven.shared:maven-dependency-tree which version 3.2 still relies
on already dead eclipse aether, see:
**
[https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
* Is it possible to replace aether by maven resolver?
* Actual: error :
Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
10.1.4 ] within specified range
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
(DefaultDependencyCollector.java:652)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:394)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
(DefaultDependencyCollector.java:362)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
(DefaultDependencyCollector.java:349)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
(DefaultDependencyCollector.java:254)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
(DefaultRepositorySystem.java:284)
at
org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
[jira] [Commented] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653409#comment-17653409
]
Gwénaël Ruelland commented on MNG-7657:
---
if i replace [10.1.4] by 10.1.4 the build succeed because 10.1.4 exists, see
[https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/10.1.4/]
what if found surprising is the build succeed with 10.1.4 but fails with
[10.1.4]
i would like to make a PR, but is eclipse aether dead ?
can i replace it by maven resolver ?
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> * What i did, pom with:
> ** property:
> [ 10.1.4 ]
> ** dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> ** running goal site with deps convergence report
> * Expected: a warning instead of an error telling the version exist but not
> ref in metadata.
> the resolver should try the exact version before calling there are none.
> [https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
> * A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
> on org.apache.maven.shared:maven-dependency-tree which version 3.2 still
> relies on already dead eclipse aether, see:
> **
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> ** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
> * Is it possible to replace aether by maven resolver?
> * Actual: error :
> {noformat}
> Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
> versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
> 10.1.4 ] within specified range
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
> (DefaultDependencyCollector.java:652)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:394)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
> (DefaultDependencyCollector.java:254)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
> (DefaultRepositorySystem.java:284)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
> (Maven31DependencyCollectorBuilder.java:136)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
> (DefaultDependencyCollectorBuilder.java:72)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
> (DependencyConvergenceReport.java:905)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
> (DependencyConvergenceReport.java:747)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
> (DependencyConvergenceReport.java:160)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:289)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:226)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653410#comment-17653410
]
Gwénaël Ruelland commented on MNG-7657:
---
you might be wondering why i use this peculiar range but it also fails with the
range i want to use which is
[ 10.1.4 , 10.2-alpha )
i would like the resolver to pick 10.1.4 and automatically pick later 10.1.6 or
whatever without me having to change 10.1.4 by 10.1.6 in the pom
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> * What i did, pom with:
> ** property:
> [ 10.1.4 ]
> ** dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> ** running goal site with deps convergence report
> * Expected: a warning instead of an error telling the version exist but not
> ref in metadata.
> the resolver should try the exact version before calling there are none.
> [https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
> * A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
> on org.apache.maven.shared:maven-dependency-tree which version 3.2 still
> relies on already dead eclipse aether, see:
> **
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> ** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
> * Is it possible to replace aether by maven resolver?
> * Actual: error :
> {noformat}
> Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
> versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
> 10.1.4 ] within specified range
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
> (DefaultDependencyCollector.java:652)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:394)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
> (DefaultDependencyCollector.java:254)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
> (DefaultRepositorySystem.java:284)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
> (Maven31DependencyCollectorBuilder.java:136)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
> (DefaultDependencyCollectorBuilder.java:72)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
> (DependencyConvergenceReport.java:905)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
> (DependencyConvergenceReport.java:747)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
> (DependencyConvergenceReport.java:160)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:289)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:226)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7657) Existing version not resolved
[
https://issues.apache.org/jira/browse/MNG-7657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653418#comment-17653418
]
Gwénaël Ruelland commented on MNG-7657:
---
does that mean i must open a Jira on maven central to make them update? i am
not sure about the replication process from repo to repo.
i have several, about 5 to 6, others artefacts that have the same problem
> Existing version not resolved
> -
>
> Key: MNG-7657
> URL: https://issues.apache.org/jira/browse/MNG-7657
> Project: Maven
> Issue Type: Bug
>Reporter: Gwénaël Ruelland
>Priority: Major
>
> * What i did, pom with:
> ** property:
> [ 10.1.4 ]
> ** dependency:
> org.apache.tomcat.embedtomcat-embed-websocket${version.org.apache.tomcat}runtime
> ** running goal site with deps convergence report
> * Expected: a warning instead of an error telling the version exist but not
> ref in metadata.
> the resolver should try the exact version before calling there are none.
> [https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/maven-metadata.xml]
> * A possible related problem: maven-project-info-reports-plugin 3.4.1 relies
> on org.apache.maven.shared:maven-dependency-tree which version 3.2 still
> relies on already dead eclipse aether, see:
> **
> [https://github.com/apache/maven-project-info-reports-plugin/blob/master/pom.xml]
> ** [https://github.com/apache/maven-dependency-tree/blob/master/pom.xml]
> * Is it possible to replace aether by maven resolver?
> * Actual: error :
> {noformat}
> Caused by: org.eclipse.aether.resolution.VersionRangeResolutionException: No
> versions available for org.apache.tomcat.embed:tomcat-embed-websocket:jar:[
> 10.1.4 ] within specified range
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.filterVersions
> (DefaultDependencyCollector.java:652)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:394)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:362)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:349)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies
> (DefaultDependencyCollector.java:254)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies
> (DefaultRepositorySystem.java:284)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyCollectorBuilder.collectDependencyGraph
> (Maven31DependencyCollectorBuilder.java:136)
> at
> org.apache.maven.shared.dependency.graph.internal.DefaultDependencyCollectorBuilder.collectDependencyGraph
> (DefaultDependencyCollectorBuilder.java:72)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.getNode
> (DependencyConvergenceReport.java:905)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.analyzeDependencyTree
> (DependencyConvergenceReport.java:747)
> at
> org.apache.maven.report.projectinfo.DependencyConvergenceReport.executeReport
> (DependencyConvergenceReport.java:160)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:289)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument
> (ReportDocumentRenderer.java:226)
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSCRIPTING-11) Lifecycle
Hüseyin Kartal created MSCRIPTING-11: Summary: Lifecycle Key: MSCRIPTING-11 URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 Project: Maven Scripting Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Hüseyin Kartal Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6913) Use Java 8
[ https://issues.apache.org/jira/browse/MNG-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653588#comment-17653588 ] Petr Široký commented on MNG-6913: -- I think this one can be closed as the change has been applied as part of different commit: https://github.com/apache/maven-integration-testing/blob/31dff13ceb2dab4b358c1ca74b356bbeade26bb3/pom.xml#L71 > Use Java 8 > -- > > Key: MNG-6913 > URL: https://issues.apache.org/jira/browse/MNG-6913 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Maarten Mulders >Priority: Trivial > > It would be great if we could use Java 8 constructs and API's in the > Integration Test project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-86) Trim trailing slash in Repo URL
Björn Michael created MWRAPPER-86:
-
Summary: Trim trailing slash in Repo URL
Key: MWRAPPER-86
URL: https://issues.apache.org/jira/browse/MWRAPPER-86
Project: Maven Wrapper
Issue Type: Bug
Components: Maven Wrapper Plugin
Affects Versions: 3.1.1
Reporter: Björn Michael
If repository URL ends with a trailing slash then the URLs in
{{maven-wrapper.properties}} contain double slashes.
E.g. {{MVNW_REPOURL=[https://myrepo.local/]}} ends up with
{code:java}
distributionUrl=https://myrepo.local//org/apache/maven/apache-maven/3.8.7/apache-maven-3.8.7-bin.zip
wrapperUrl=https://myrepo.local//org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1.jar{code}
This also occurs when mirror * URL ends with trailing slash.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MWRAPPER-86) Trim trailing slash in Repo URL
[
https://issues.apache.org/jira/browse/MWRAPPER-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17654146#comment-17654146
]
Björn Michael commented on MWRAPPER-86:
---
The URLs were corrected manually after the double slashes were discovered.
Examples in [RFC3986|https://www.rfc-editor.org/rfc/rfc3986] use single slash
syntax. {{a/b/c}} and {{a/b//c}} technically represent different paths but are
irrelevant for repository URL here.
??So: yes, it is valid, no, don't use it.??
[https://stackoverflow.com/questions/20523318/is-a-url-with-in-the-path-section-valid]
??As mentioned by
[@RandomBen|https://webmasters.stackexchange.com/questions/8354/what-does-the-double-slash-mean-in-urls/8356#8356],
the double slash is most likely the result of an error somewhere.??
[https://webmasters.stackexchange.com/questions/8354/what-does-a-double-slash-in-the-url-path-mean]
> Trim trailing slash in Repo URL
> ---
>
> Key: MWRAPPER-86
> URL: https://issues.apache.org/jira/browse/MWRAPPER-86
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Plugin
>Affects Versions: 3.1.1
>Reporter: Björn Michael
>Priority: Major
>
> If repository URL ends with a trailing slash then the URLs in
> {{maven-wrapper.properties}} contain double slashes.
> E.g. {{MVNW_REPOURL=[https://myrepo.local/]}} ends up with
> {code:java}
> distributionUrl=https://myrepo.local//org/apache/maven/apache-maven/3.8.7/apache-maven-3.8.7-bin.zip
> wrapperUrl=https://myrepo.local//org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1.jar{code}
> This also occurs when mirror * URL ends with trailing slash.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-87) Provide a switch to use default repository URL
Björn Michael created MWRAPPER-87:
-
Summary: Provide a switch to use default repository URL
Key: MWRAPPER-87
URL: https://issues.apache.org/jira/browse/MWRAPPER-87
Project: Maven Wrapper
Issue Type: Improvement
Components: Maven Wrapper Plugin
Affects Versions: 3.1.1
Reporter: Björn Michael
When mirrors are used in {{settings.xml}} then the repository URL in
{{maven-wrapper.properties}} also contains this mirror. This behavior is
sometimes unwanted e.g. local maven configuration differs from project
configuration. Thus provide a mean like a system property that enforces the
default repository URL ([https://repo.maven.apache.org/maven2] at the moment).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7661) Fix IT build / compiler warnings
Petr Široký created MNG-7661:
Summary: Fix IT build / compiler warnings
Key: MNG-7661
URL: https://issues.apache.org/jira/browse/MNG-7661
Project: Maven
Issue Type: Task
Components: Integration Tests
Reporter: Petr Široký
I noticed there is a quite a few build (from Maven) and also compiler warnings
(e.g. using deprecated verifier APIs) when running the integration tests.
I noticed following:
* {{maven-plugin-plugin}} complains about Maven deps which should be in
{{provided}} scope
{code:java}
[INFO] --- maven-plugin-plugin:3.6.4:descriptor (default-descriptor) @
maven-it-plugin-bootstrap ---
[ERROR] Some dependencies of Maven Plugins are expected to be in provided scope.
Please make sure that dependencies listed below declared in POM
have set 'provided' as well.The following dependencies are in
wrong scope:
* org.apache.maven:maven-plugin-api:jar:3.8.6:compile
* org.apache.maven:maven-model:jar:3.8.6:compile
* org.apache.maven:maven-artifact:jar:3.8.6:compile
* org.apache.maven:maven-core:jar:3.8.6:compile
* org.apache.maven:maven-settings:jar:3.8.6:compile
* org.apache.maven:maven-settings-builder:jar:3.8.6:compile
* org.apache.maven:maven-builder-support:jar:3.8.6:compile
* org.apache.maven:maven-repository-metadata:jar:3.8.6:compile
* org.apache.maven:maven-model-builder:jar:3.8.6:compile
* org.apache.maven:maven-resolver-provider:jar:3.8.6:compile
{code}
* several deprecated maven-verifier methods are being used (these are not
being reported during being - I guess the warnings are disabled, but IDEA
complains)
{code:java}
verifier.executeGoal( "process-sources" );
verifier.resetStreams();
verifier.addCliOption( "--settings" ); {code}
* Jetty-related WARN (related to the fact that we the tests are using very old
version, probably not a bad idea to upgrade that)
{code:java}
26317 [qtp876069009-2062] WARN org.eclipse.jetty.util.ssl.SslContextFactory -
EXCEPTION
java.lang.UnsupportedOperationException: This method is deprecated and marked
for removal. Use the getPeerCertificates() method instead.
at
java.base/javax.net.ssl.SSLSession.getPeerCertificateChain(SSLSession.java:295)
at
org.eclipse.jetty.util.ssl.SslContextFactory.getCertChain(SslContextFactory.java:1393)
at
org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:104)
at
org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:54)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:266)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
at java.base/java.lang.Thread.run(Thread.java:833) {code}
I would like to take a look at those and create small(ish) PRs with suggested
fixes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7661) Fix IT build / compiler warnings
[
https://issues.apache.org/jira/browse/MNG-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Široký updated MNG-7661:
-
Description:
I noticed there is a quite a few build (from Maven) and also compiler warnings
(e.g. using deprecated verifier APIs) when running the integration tests.
I noticed following:
* {{maven-plugin-plugin}} complains about Maven deps which should be in
{{provided}} scope
{code:java}
[INFO] --- maven-plugin-plugin:3.6.4:descriptor (default-descriptor) @
maven-it-plugin-bootstrap ---
[ERROR] Some dependencies of Maven Plugins are expected to be in provided scope.
Please make sure that dependencies listed below declared in POM
have set 'provided' as well.The following dependencies are in
wrong scope:
* org.apache.maven:maven-plugin-api:jar:3.8.6:compile
* org.apache.maven:maven-model:jar:3.8.6:compile
* org.apache.maven:maven-artifact:jar:3.8.6:compile
* org.apache.maven:maven-core:jar:3.8.6:compile
* org.apache.maven:maven-settings:jar:3.8.6:compile
* org.apache.maven:maven-settings-builder:jar:3.8.6:compile
* org.apache.maven:maven-builder-support:jar:3.8.6:compile
* org.apache.maven:maven-repository-metadata:jar:3.8.6:compile
* org.apache.maven:maven-model-builder:jar:3.8.6:compile
* org.apache.maven:maven-resolver-provider:jar:3.8.6:compile
{code}
* several deprecated maven-verifier methods are being used (these are not
being reported during being - I guess the warnings are disabled, but IDEA
complains)
{code:java}
verifier.executeGoal( "process-sources" );
verifier.resetStreams();
verifier.addCliOption( "--settings" ); {code}
* Jetty- WARN (related to the fact that the tests are using very old version,
probably not a bad idea to upgrade that)
{code:java}
26317 [qtp876069009-2062] WARN org.eclipse.jetty.util.ssl.SslContextFactory -
EXCEPTION
java.lang.UnsupportedOperationException: This method is deprecated and marked
for removal. Use the getPeerCertificates() method instead.
at
java.base/javax.net.ssl.SSLSession.getPeerCertificateChain(SSLSession.java:295)
at
org.eclipse.jetty.util.ssl.SslContextFactory.getCertChain(SslContextFactory.java:1393)
at
org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:104)
at
org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:54)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:266)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
at java.base/java.lang.Thread.run(Thread.java:833) {code}
I would like to take a look at those and create small(ish) PRs with suggested
fixes.
was:
I noticed there is a quite a few build (from Maven) and also compiler warnings
(e.g. using deprecated verifier APIs) when running the integration tests.
I noticed following:
* {{maven-plugin-plugin}} complains about Maven deps which should be in
{{provided}} scope
{code:java}
[INFO] --- maven-plugin-plugin:3.6.4:descriptor (default-descriptor) @
maven-it-plugin-bootstrap ---
[ERROR] Some dependencies of Maven Plugins are expected to be in provided scope.
Please make sure that dependencies listed below declared in POM
have set 'provided' as well.The following dependencies are in
wrong scope:
* org.apache.maven:maven-plugin-api:jar:3.8.6:compile
* org.apache.maven:maven-model:jar:3.8.6:compile
* org.apache.maven:maven-artifact:jar:3.8.6:compile
* org.apache.maven:maven-core:jar:3.8.6:compile
* org.apache.maven:maven-settings:jar:3.8.6:compile
* org.apache.maven:maven-settings-builder:jar:3.8.6:compile
* org.apache.maven:maven-builder-support:jar:3.8.6:compile
* org.apache.maven:maven-repository-metadata:jar:3.8.6:compile
* org.apache.maven:maven-model-builder:jar:3.8.6:compile
* org.apache.maven:maven-resolver-provider:jar:3.8.6:compile
{code}
* several deprecated maven-verifier methods are being used (these are not
being reported during being - I guess the warnings are disabled, but IDEA
complains)
{code:java}
verifier.executeGoal( "process-sources" );
verifier.resetStreams();
verifier.addCliOption( "--settings" ); {code}
* Jetty-related WARN (related to the fact that we the tests are using very old
version, probably not a bad idea to upgrade that)
{code:java}
26317 [qtp876069009-2062] WARN org.eclipse.jetty.util.ssl.SslContextFactory -
EXCEPTION
java.lang.UnsupportedOperationException: This method is deprecated and marked
for removal. Use the getPeerCertificates() method instead.
at
java.base/javax.net.ssl.SS
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17654441#comment-17654441
]
Christoph Läubrich commented on MNG-7038:
-
Maybe a ${project.parent.basedir} would be useful as well that simply points
the parents folder?
I think that the description here is different from what
"maven.multiModuleProjectDirectory" does, because this is independent from the
parent/child relations, while here is is proposed that parent-child relation
matters. But both can have use-cases so why not just standardize
"maven.multiModuleProjectDirectory" and still keep this one for further
improvements?
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7662) Allow Graphbuilder to use session scoped components
Christoph Läubrich created MNG-7662:
---
Summary: Allow Graphbuilder to use session scoped components
Key: MNG-7662
URL: https://issues.apache.org/jira/browse/MNG-7662
Project: Maven
Issue Type: Bug
Reporter: Christoph Läubrich
Currently DefaultMaven gets the Graphbuilder injected as a strict requirement
at a very early stage. This leads to the problem, that a GraphBuilder
implementation can not use any SessionScoped Components (because the session
scope is not setup yet).
The error then is
{code:java}
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.execution.MavenSession, annotation=[none]]
outside of a scoping block
at
org.apache.maven.session.scope.internal.SessionScopeModule.configure(SessionScopeModule.java:64)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
while locating org.apache.maven.execution.MavenSession
for the 1st parameter of
org.eclipse.tycho.helper.PluginRealmHelper.(Unknown Source)
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.helper.PluginRealmHelper
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.InstallableUnitGenerator
at ClassRealm[coreExtension>org.eclipse.tycho:tycho-build:${tycho-version},
parent: ClassRealm[plexus.core, parent: null]] (via modules:
org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
while locating org.eclipse.tycho.p2maven.MavenProjectDependencyProcessor
while locating org.eclipse.tycho.build.TychoGraphBuilder
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7661) Fix IT build / compiler warnings
[
https://issues.apache.org/jira/browse/MNG-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Široký updated MNG-7661:
-
Description:
I noticed there is a quite a few build (from Maven) and also compiler warnings
(e.g. using deprecated verifier APIs) when running the integration tests.
I noticed following:
* {{maven-plugin-plugin}} complains about Maven deps which should be in
{{provided}} scope
{code:java}
[INFO] --- maven-plugin-plugin:3.6.4:descriptor (default-descriptor) @
maven-it-plugin-bootstrap ---
[ERROR] Some dependencies of Maven Plugins are expected to be in provided scope.
Please make sure that dependencies listed below declared in POM
have set 'provided' as well.The following dependencies are in
wrong scope:
* org.apache.maven:maven-plugin-api:jar:3.8.6:compile
* org.apache.maven:maven-model:jar:3.8.6:compile
* org.apache.maven:maven-artifact:jar:3.8.6:compile
* org.apache.maven:maven-core:jar:3.8.6:compile
* org.apache.maven:maven-settings:jar:3.8.6:compile
* org.apache.maven:maven-settings-builder:jar:3.8.6:compile
* org.apache.maven:maven-builder-support:jar:3.8.6:compile
* org.apache.maven:maven-repository-metadata:jar:3.8.6:compile
* org.apache.maven:maven-model-builder:jar:3.8.6:compile
* org.apache.maven:maven-resolver-provider:jar:3.8.6:compile
{code}
* several deprecated maven-verifier methods are being used (these are not
being reported by Maven during builds - I guess the warnings are disabled, but
IDEA complains)
{code:java}
verifier.executeGoal( "process-sources" );
verifier.resetStreams();
verifier.addCliOption( "--settings" ); {code}
* Jetty- WARN (related to the fact that the tests are using very old version,
probably not a bad idea to upgrade that)
{code:java}
26317 [qtp876069009-2062] WARN org.eclipse.jetty.util.ssl.SslContextFactory -
EXCEPTION
java.lang.UnsupportedOperationException: This method is deprecated and marked
for removal. Use the getPeerCertificates() method instead.
at
java.base/javax.net.ssl.SSLSession.getPeerCertificateChain(SSLSession.java:295)
at
org.eclipse.jetty.util.ssl.SslContextFactory.getCertChain(SslContextFactory.java:1393)
at
org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:104)
at
org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:54)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:266)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
at java.base/java.lang.Thread.run(Thread.java:833) {code}
I would like to take a look at those and create small(ish) PRs with suggested
fixes.
was:
I noticed there is a quite a few build (from Maven) and also compiler warnings
(e.g. using deprecated verifier APIs) when running the integration tests.
I noticed following:
* {{maven-plugin-plugin}} complains about Maven deps which should be in
{{provided}} scope
{code:java}
[INFO] --- maven-plugin-plugin:3.6.4:descriptor (default-descriptor) @
maven-it-plugin-bootstrap ---
[ERROR] Some dependencies of Maven Plugins are expected to be in provided scope.
Please make sure that dependencies listed below declared in POM
have set 'provided' as well.The following dependencies are in
wrong scope:
* org.apache.maven:maven-plugin-api:jar:3.8.6:compile
* org.apache.maven:maven-model:jar:3.8.6:compile
* org.apache.maven:maven-artifact:jar:3.8.6:compile
* org.apache.maven:maven-core:jar:3.8.6:compile
* org.apache.maven:maven-settings:jar:3.8.6:compile
* org.apache.maven:maven-settings-builder:jar:3.8.6:compile
* org.apache.maven:maven-builder-support:jar:3.8.6:compile
* org.apache.maven:maven-repository-metadata:jar:3.8.6:compile
* org.apache.maven:maven-model-builder:jar:3.8.6:compile
* org.apache.maven:maven-resolver-provider:jar:3.8.6:compile
{code}
* several deprecated maven-verifier methods are being used (these are not
being reported during being - I guess the warnings are disabled, but IDEA
complains)
{code:java}
verifier.executeGoal( "process-sources" );
verifier.resetStreams();
verifier.addCliOption( "--settings" ); {code}
* Jetty- WARN (related to the fact that the tests are using very old version,
probably not a bad idea to upgrade that)
{code:java}
26317 [qtp876069009-2062] WARN org.eclipse.jetty.util.ssl.SslContextFactory -
EXCEPTION
java.lang.UnsupportedOperationException: This method is deprecated and marked
for removal. Use the getPeerCertificates() method instead.
at
java.base/javax.net.ssl.SS
[jira] [Created] (MCOMPILER-519) Upgrade maven-invoker-plugin from 3.3.0 to 3.4.0
Petr Široký created MCOMPILER-519: - Summary: Upgrade maven-invoker-plugin from 3.3.0 to 3.4.0 Key: MCOMPILER-519 URL: https://issues.apache.org/jira/browse/MCOMPILER-519 Project: Maven Compiler Plugin Issue Type: Dependency upgrade Reporter: Petr Široký Invoker 3.4.0 brings support for building (or more precisely running the tests) JDK 19. This is not absolutely necessary, but would be nice to support the latest JDK. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7661) Fix IT build / compiler warnings
[
https://issues.apache.org/jira/browse/MNG-7661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Široký updated MNG-7661:
-
Description:
I noticed there is a quite a few build (from Maven) and also compiler warnings
(e.g. using deprecated verifier APIs) when running the integration tests.
I noticed following:
* {{maven-plugin-plugin}} complains about Maven deps which should be in
{{provided}} scope
{code:java}
[INFO] --- maven-plugin-plugin:3.6.4:descriptor (default-descriptor) @
maven-it-plugin-bootstrap ---
[ERROR] Some dependencies of Maven Plugins are expected to be in provided scope.
Please make sure that dependencies listed below declared in POM
have set 'provided' as well.The following dependencies are in
wrong scope:
* org.apache.maven:maven-plugin-api:jar:3.8.6:compile
* org.apache.maven:maven-model:jar:3.8.6:compile
* org.apache.maven:maven-artifact:jar:3.8.6:compile
* org.apache.maven:maven-core:jar:3.8.6:compile
* org.apache.maven:maven-settings:jar:3.8.6:compile
* org.apache.maven:maven-settings-builder:jar:3.8.6:compile
* org.apache.maven:maven-builder-support:jar:3.8.6:compile
* org.apache.maven:maven-repository-metadata:jar:3.8.6:compile
* org.apache.maven:maven-model-builder:jar:3.8.6:compile
* org.apache.maven:maven-resolver-provider:jar:3.8.6:compile
{code}
* several deprecated maven-verifier methods are being used (these are not
being reported by Maven during builds - I guess the warnings are disabled, but
IDEA complains)
{code:java}
verifier.executeGoal( "process-sources" );
verifier.resetStreams();
verifier.addCliOption( "--settings" ); {code}
* -Jetty WARN (related to the fact that the tests are using very old version,
probably not a bad idea to upgrade that)-
{code:java}
26317 [qtp876069009-2062] WARN org.eclipse.jetty.util.ssl.SslContextFactory -
EXCEPTION
java.lang.UnsupportedOperationException: This method is deprecated and marked
for removal. Use the getPeerCertificates() method instead.
at
java.base/javax.net.ssl.SSLSession.getPeerCertificateChain(SSLSession.java:295)
at
org.eclipse.jetty.util.ssl.SslContextFactory.getCertChain(SslContextFactory.java:1393)
at
org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:104)
at
org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:54)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:266)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
at java.base/java.lang.Thread.run(Thread.java:833) {code}
*
** the WARN was fixed by upgrading Jetty as part of
https://issues.apache.org/jira/browse/MNG-7665
I would like to take a look at those and create small(ish) PRs with suggested
fixes.
was:
I noticed there is a quite a few build (from Maven) and also compiler warnings
(e.g. using deprecated verifier APIs) when running the integration tests.
I noticed following:
* {{maven-plugin-plugin}} complains about Maven deps which should be in
{{provided}} scope
{code:java}
[INFO] --- maven-plugin-plugin:3.6.4:descriptor (default-descriptor) @
maven-it-plugin-bootstrap ---
[ERROR] Some dependencies of Maven Plugins are expected to be in provided scope.
Please make sure that dependencies listed below declared in POM
have set 'provided' as well.The following dependencies are in
wrong scope:
* org.apache.maven:maven-plugin-api:jar:3.8.6:compile
* org.apache.maven:maven-model:jar:3.8.6:compile
* org.apache.maven:maven-artifact:jar:3.8.6:compile
* org.apache.maven:maven-core:jar:3.8.6:compile
* org.apache.maven:maven-settings:jar:3.8.6:compile
* org.apache.maven:maven-settings-builder:jar:3.8.6:compile
* org.apache.maven:maven-builder-support:jar:3.8.6:compile
* org.apache.maven:maven-repository-metadata:jar:3.8.6:compile
* org.apache.maven:maven-model-builder:jar:3.8.6:compile
* org.apache.maven:maven-resolver-provider:jar:3.8.6:compile
{code}
* several deprecated maven-verifier methods are being used (these are not
being reported by Maven during builds - I guess the warnings are disabled, but
IDEA complains)
{code:java}
verifier.executeGoal( "process-sources" );
verifier.resetStreams();
verifier.addCliOption( "--settings" ); {code}
* Jetty- WARN (related to the fact that the tests are using very old version,
probably not a bad idea to upgrade that)
{code:java}
26317 [qtp876069009-2062] WARN org.eclipse.jetty.util.ssl.SslContextFactory -
EXCEPTION
java.lang.UnsupportedOperationException: This method is deprecated and marked
for removal. Use
[jira] [Created] (MCOMPILER-520) Upgrade parent to version 39
Petr Široký created MCOMPILER-520: - Summary: Upgrade parent to version 39 Key: MCOMPILER-520 URL: https://issues.apache.org/jira/browse/MCOMPILER-520 Project: Maven Compiler Plugin Issue Type: Dependency upgrade Reporter: Petr Široký Maven itself and other plugins are being migrated to this new parent versions as well. It brings in new formatting rules (using spotless) so reformatting of the whole code base will be required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-522) Use maven-resolver to resolve 'annotationProcessorPaths' dependencies
Petr Široký created MCOMPILER-522:
-
Summary: Use maven-resolver to resolve 'annotationProcessorPaths'
dependencies
Key: MCOMPILER-522
URL: https://issues.apache.org/jira/browse/MCOMPILER-522
Project: Maven Compiler Plugin
Issue Type: Improvement
Affects Versions: 3.10.1
Reporter: Petr Široký
The dependency resolution of {{annotationProcessorPaths}} currently relies on
the old approach using e.g. {{org.apache.maven.repository.RepositorySystem}}
and related classes. We should move / migrate to the {{maven-resolver}} APIs.
There is already a Draft PR with these changes:
[https://github.com/apache/maven-compiler-plugin/pull/151.]
I am creating this JIRA for tracking purposes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-522) Use maven-resolver to resolve 'annotationProcessorPaths' dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678614#comment-17678614
]
Petr Široký commented on MCOMPILER-522:
---
As discussed in https://github.com/apache/maven-compiler-plugin/pull/151 I will
take over this one.
> Use maven-resolver to resolve 'annotationProcessorPaths' dependencies
> -
>
> Key: MCOMPILER-522
> URL: https://issues.apache.org/jira/browse/MCOMPILER-522
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.10.1
>Reporter: Petr Široký
>Priority: Major
>
> The dependency resolution of {{annotationProcessorPaths}} currently relies on
> the old approach using e.g. {{org.apache.maven.repository.RepositorySystem}}
> and related classes. We should move / migrate to the {{maven-resolver}} APIs.
> There is already a Draft PR with these changes:
> [https://github.com/apache/maven-compiler-plugin/pull/151]
> I am creating this JIRA for tracking purposes.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-522) Use maven-resolver to resolve 'annotationProcessorPaths' dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Široký updated MCOMPILER-522:
--
Description:
The dependency resolution of {{annotationProcessorPaths}} currently relies on
the old approach using e.g. {{org.apache.maven.repository.RepositorySystem}}
and related classes. We should move / migrate to the {{maven-resolver}} APIs.
There is already a Draft PR with these changes:
[https://github.com/apache/maven-compiler-plugin/pull/151]
I am creating this JIRA for tracking purposes.
was:
The dependency resolution of {{annotationProcessorPaths}} currently relies on
the old approach using e.g. {{org.apache.maven.repository.RepositorySystem}}
and related classes. We should move / migrate to the {{maven-resolver}} APIs.
There is already a Draft PR with these changes:
[https://github.com/apache/maven-compiler-plugin/pull/151.]
I am creating this JIRA for tracking purposes.
> Use maven-resolver to resolve 'annotationProcessorPaths' dependencies
> -
>
> Key: MCOMPILER-522
> URL: https://issues.apache.org/jira/browse/MCOMPILER-522
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.10.1
>Reporter: Petr Široký
>Priority: Major
>
> The dependency resolution of {{annotationProcessorPaths}} currently relies on
> the old approach using e.g. {{org.apache.maven.repository.RepositorySystem}}
> and related classes. We should move / migrate to the {{maven-resolver}} APIs.
> There is already a Draft PR with these changes:
> [https://github.com/apache/maven-compiler-plugin/pull/151]
> I am creating this JIRA for tracking purposes.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7669) Add artifact-type for Tycho
Christoph Läubrich created MNG-7669: --- Summary: Add artifact-type for Tycho Key: MNG-7669 URL: https://issues.apache.org/jira/browse/MNG-7669 Project: Maven Issue Type: Improvement Reporter: Christoph Läubrich Since a while Tycho is going more and more "maven-like" so today even more Tycho artifacts approaching at maven-central. In some circumstances this leads to strange problems, because Dependencies have a *type* (usually the packaging type) but artifacts have an *extension* (where different packaging types often map to the same extension), and maven only includes a few mappings by default users currently need to enable an extension so that this works. I therefore like to gently ask adding a mapping to the default maven supported list that maps tycho-plugin (*type*) -> jar (*extension*). It would be great if it could be included in maven 3.9.0 (would be a good argument to move on to newer maven version for our users!)! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7630) Support listing of workspace models and implement upcomming interface methods
[ https://issues.apache.org/jira/browse/MNG-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678989#comment-17678989 ] Christoph Läubrich commented on MNG-7630: - Can someone with more JIRA power than me please close this? > Support listing of workspace models and implement upcomming interface methods > - > > Key: MNG-7630 > URL: https://issues.apache.org/jira/browse/MNG-7630 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-4, 4.0.0 > > > This is the Maven counterpart of MRESOLVER-307. > As this will be most likely be released in resolver 2.0 only maven can still > already have an implementation for the new methods to: > - show how they would look like > - if upgrading source is already prepared > - Maven has an own extension of that interface that should have similar > behaviour -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-307) Support listing of workspace artifacts
[
https://issues.apache.org/jira/browse/MRESOLVER-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678992#comment-17678992
]
Christoph Läubrich commented on MRESOLVER-307:
--
Can someone with more JIRA power than me please close this?
> Support listing of workspace artifacts
> --
>
> Key: MRESOLVER-307
> URL: https://issues.apache.org/jira/browse/MRESOLVER-307
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> Currently the WorkspaceReader has a way to list versions or resolve the file
> for an artifact, but there is no way of really get a list of workspace
> artifacts itself.
> The javadoc states:
> {quote}Manages a repository backed by the IDE workspace, a build session or a
> similar ad-hoc collection of artifacts.{quote}
> so the goal is to have a way getting hold of the "collection of artifacts"
> this Workspacereader manages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1179) Upgrade Parent to 39
Jorge Solórzano created MSHARED-1179: Summary: Upgrade Parent to 39 Key: MSHARED-1179 URL: https://issues.apache.org/jira/browse/MSHARED-1179 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-archiver Reporter: Jorge Solórzano -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-496) The resolve process of annotationProcessorPaths is not aware of WorkspaceReader
[
https://issues.apache.org/jira/browse/MCOMPILER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680375#comment-17680375
]
Petr Široký commented on MCOMPILER-496:
---
I believe this has been fixed as part of MCOMPILER-522.
When running the ITs (e.g. {{MCOMPILER-203-processorpath}}), I seeing am the
following output:
{code}
...
-processorpath
/maven-compiler-plugin/target/it/MCOMPILER-203-processorpath/annotation-processor/target/classes:/maven-compiler-plugin/target/local-repo/org/apache/commons/commons-lang3/3.4/commons-lang3-3.4.jar
...
{code}
which I think suggests that now the annotation-processor is "picked-up" from
the multi module build.
> The resolve process of annotationProcessorPaths is not aware of
> WorkspaceReader
> ---
>
> Key: MCOMPILER-496
> URL: https://issues.apache.org/jira/browse/MCOMPILER-496
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Reporter: Tamas Cservenak
>Priority: Major
>
> Hence, it cannot resolve annotation processor from current multi module
> build, and it requires annotation processor to be installed/downloaded.
> Move off from legacy API and use something like maven-artifact-transfer
> instead of maven-compat that delivers Maven2 behaviour.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MWRAPPER-93) Distribution sha256 checksum not validated if the zip file was downloaded previously
Jorge Solórzano created MWRAPPER-93: --- Summary: Distribution sha256 checksum not validated if the zip file was downloaded previously Key: MWRAPPER-93 URL: https://issues.apache.org/jira/browse/MWRAPPER-93 Project: Maven Wrapper Issue Type: Bug Components: Maven Wrapper Jar Affects Versions: 3.2.0 Reporter: Jorge Solórzano If I make a first run without *distributionSha256Sum*, the Maven distribution will be downloaded without any checksum, this is the normal behavior. But if I later add the *distributionSha256Sum* to the maven-wrapper.properties file, having downloaded previously the distribution, the checksum is not verified, I consider this a bug since even if the distribution is already downloaded and unpacked it could contain a compromised download. The options *alwaysUnpack* and *alwaysDownload* triggers the verification and provides an extra layer of security, but normally the local zip should be verified always if the *distributionSha256Sum* is set. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-524) Please use usefull defaults
Christoph Läubrich created MCOMPILER-524:
Summary: Please use usefull defaults
Key: MCOMPILER-524
URL: https://issues.apache.org/jira/browse/MCOMPILER-524
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: Christoph Läubrich
I have this absolute minimal pom:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
test
minimal
0.0.1-SNAPSHOT
{code}
executing this with maven fails with:
{code:java}
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] Source option 5 is no longer supported. Use 7 or later.
[ERROR] Target option 5 is no longer supported. Use 7 or later.
{code}
As I have configured nothing, as a user I would expect that the defaults are
something that at least can work and do not fail, or gives a strong indication
that some kind of configuration is required but missing. In this case it would
even be appropriate to instead have an error to issue a warning that level 7 is
used instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681285#comment-17681285 ] Hüseyin Kartal commented on MSCRIPTING-11: -- I understand. But credentials can be encrypted in settings if it is a security issue. Anyways i don't rely on "settings". But i need the current maven lifecycle phase which is available in the mojoExecution. Is it ok to add that. Currently i want to migrate an ant build to maven and have two usecases where i want to use the scripting plugin. # I need to call some java classes for generation of sources and resources. For this i want to determine the current lifecycle phase of the maven execution. And because i don't want to fragment the script i need the mojoExecution for that. # Some artifacts are not available in repositories. And because i don't want to uses dependencies in system scope i install them within a script into the local repository. > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-525) Incremental recompile incorrect detection of dependency change
Jorge Solórzano created MCOMPILER-525: - Summary: Incremental recompile incorrect detection of dependency change Key: MCOMPILER-525 URL: https://issues.apache.org/jira/browse/MCOMPILER-525 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.10.1 Reporter: Jorge Solórzano I have just hit an issue running the ITs of maven-jar-plugin, specifically the *MJAR-70-no-recreation* test on Maven 3.9.0-SNAPSHOT. Trying to debug the issue I just found out that the issue is not related to Maven 3.9.0-SNAPSHOT but the real issue seems related to the maven-compiler-plugin used by default on that version. maven-compiler-plugins tries to detect changes on incremental compilation running *isDependencyChanged()* which in turn executes *hasNewFile()* but during the same run of maven, if the compile phase is run twice it would not detect correctly that nothing has changed since is just evaluating the file time of the class but the class ends up being newer than the buildStartTime, so this causes the recompilation. My proposal is to add a step to set the last modification time if the incremental compilation is enabled and that way it will use the exact same time than the buildStartTime() from maven. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-489) User property for multiReleaseOutput
[ https://issues.apache.org/jira/browse/MCOMPILER-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681642#comment-17681642 ] Jorge Solórzano commented on MCOMPILER-489: --- Yes, this doesn't make sense to me, that would completely break the intention of different releases. I agree that multi release jars is a half baked feature everywhere, the IDEs don't really provide good support for it and Maven has some limitations with the configuration, but just providing a user property would not improve the situation at all. > User property for multiReleaseOutput > > > Key: MCOMPILER-489 > URL: https://issues.apache.org/jira/browse/MCOMPILER-489 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: John Patrick >Priority: Minor > Labels: CompilerOptions > > Add support so multiReleaseOutput can be provided as a user property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681647#comment-17681647 ] Hüseyin Kartal commented on MSCRIPTING-11: -- I also want to use the org.apache.maven.shared.incremental.IncrementalBuildHelper and that needs the MojoExecution, MavenSession and MavenProject. > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681647#comment-17681647 ] Hüseyin Kartal edited comment on MSCRIPTING-11 at 1/28/23 11:03 PM: I also want to use the org.apache.maven.shared.incremental.IncrementalBuildHelper in both usescases. To instantiate it MojoExecution, MavenSession and MavenProject needed. was (Author: hsyn): I also want to use the org.apache.maven.shared.incremental.IncrementalBuildHelper and that needs the MojoExecution, MavenSession and MavenProject. > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSCRIPTING-11) Lifecycle
[ https://issues.apache.org/jira/browse/MSCRIPTING-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681800#comment-17681800 ] Hüseyin Kartal commented on MSCRIPTING-11: -- For what is than the scripting plugin good if i don't have access to the maven context which the requested objects are mandatory part of it. Otherwise anyone can call their scripts outside from maven. I wouldn't call the enhancement making the plugin a swiss knife on the contrary it would become usefull. > Lifecycle > - > > Key: MSCRIPTING-11 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-11 > Project: Maven Scripting > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Hüseyin Kartal >Priority: Major > Labels: features, pull-request-available > > Make the current maven lifecycle phase available in the groovy script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7605) ArtifactHandler should include a method to check if this one has a compile phase
[ https://issues.apache.org/jira/browse/MNG-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681929#comment-17681929 ] Christoph Läubrich commented on MNG-7605: - 1. https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/ReactorReader.java 2. Code uses "type" of artifact: https://github.com/apache/maven/blob/fbeefb85abdc1e6d42e06c4438951d2a38d4b383/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L181 > ArtifactHandler should include a method to check if this one has a compile > phase > > > Key: MNG-7605 > URL: https://issues.apache.org/jira/browse/MNG-7605 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > > Currently ReactorReader has a hardcoded list of types that have a "compile" > phase where a reactor project is resolved to the output directory. > Instead of a hardcoded list, it would be better to ask the available > ArtifactHandler about this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7605) ArtifactHandler should include a method to check if this one has a compile phase
[ https://issues.apache.org/jira/browse/MNG-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17681929#comment-17681929 ] Christoph Läubrich edited comment on MNG-7605 at 1/30/23 8:33 AM: -- 1. https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/ReactorReader.java 2. Code uses "type" of artifact: https://github.com/apache/maven/blob/fbeefb85abdc1e6d42e06c4438951d2a38d4b383/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L181 ArtifactHandler (isAddToClasspath / isIncludeDependecies) where probably new isIncludeCompilePhase() would be added: https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java was (Author: laeubi): 1. https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/ReactorReader.java 2. Code uses "type" of artifact: https://github.com/apache/maven/blob/fbeefb85abdc1e6d42e06c4438951d2a38d4b383/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L181 > ArtifactHandler should include a method to check if this one has a compile > phase > > > Key: MNG-7605 > URL: https://issues.apache.org/jira/browse/MNG-7605 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > > Currently ReactorReader has a hardcoded list of types that have a "compile" > phase where a reactor project is resolved to the output directory. > Instead of a hardcoded list, it would be better to ask the available > ArtifactHandler about this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7605) ArtifactHandler should include a method to check if this one has a compile phase
[ https://issues.apache.org/jira/browse/MNG-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682438#comment-17682438 ] Christoph Läubrich commented on MNG-7605: - Yes, in the end it would be good to delegate all work to the ArtifactHandler, but for a first stepp COMPILE_PHASE_TYPES field with predefined constants should go away. > ArtifactHandler should include a method to check if this one has a compile > phase > > > Key: MNG-7605 > URL: https://issues.apache.org/jira/browse/MNG-7605 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > > Currently ReactorReader has a hardcoded list of types that have a "compile" > phase where a reactor project is resolved to the output directory. > Instead of a hardcoded list, it would be better to ask the available > ArtifactHandler about this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-94) mvnw fails when path contain spaces
Jorge Solórzano created MWRAPPER-94: --- Summary: mvnw fails when path contain spaces Key: MWRAPPER-94 URL: https://issues.apache.org/jira/browse/MWRAPPER-94 Project: Maven Wrapper Issue Type: Bug Reporter: Jorge Solórzano When a path contain spaces an it's called with the full path, the script get stuck and don't work. Linked external issue: https://github.com/quarkusio/quarkus/issues/30642 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-94) mvnw fails when path contain spaces
[ https://issues.apache.org/jira/browse/MWRAPPER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Solórzano updated MWRAPPER-94: Priority: Not a Priority (was: Urgent) > mvnw fails when path contain spaces > --- > > Key: MWRAPPER-94 > URL: https://issues.apache.org/jira/browse/MWRAPPER-94 > Project: Maven Wrapper > Issue Type: Bug >Reporter: Jorge Solórzano >Priority: Not a Priority > > When a path contain spaces an it's called with the full path, the script get > stuck and don't work. > Linked external issue: https://github.com/quarkusio/quarkus/issues/30642 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MWRAPPER-94) mvnw fails when path contain spaces
[ https://issues.apache.org/jira/browse/MWRAPPER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17682712#comment-17682712 ] Jorge Solórzano commented on MWRAPPER-94: - Ok, checked current code on master and the fix is already there. Please close this. > mvnw fails when path contain spaces > --- > > Key: MWRAPPER-94 > URL: https://issues.apache.org/jira/browse/MWRAPPER-94 > Project: Maven Wrapper > Issue Type: Bug >Reporter: Jorge Solórzano >Priority: Not a Priority > > When a path contain spaces an it's called with the full path, the script get > stuck and don't work. > Linked external issue: https://github.com/quarkusio/quarkus/issues/30642 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1698) Parameter "skipAfterFailureCount" no working
[
https://issues.apache.org/jira/browse/SUREFIRE-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683404#comment-17683404
]
Björn Kautler commented on SUREFIRE-1698:
-
[~tibordigana]
{quote}In our documentation we mention only JUnit4.7+ and not JUnit5.
{quote}
Actually the docs at
https://maven.apache.org/surefire/maven-surefire-plugin/examples/skip-after-failure.html
say (and also said in the past)
{quote}JUnit 4.0 or higher,
{quote}
and
{quote}Preferably use JUnit 4.12 or higher version which fixed thread safety
issues.
{quote}
which both imho includes JUnit 5, so maybe the docs should be updated until
this is supported to clearly state the no JUnit 5 engine is supported by this
flag currently.
> Parameter "skipAfterFailureCount" no working
>
>
> Key: SUREFIRE-1698
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1698
> Project: Maven Surefire
> Issue Type: Wish
> Components: Maven Surefire Plugin
>Reporter: Anton Burmakov
>Assignee: Tibor Digana
>Priority: Major
> Labels: junit5
>
> I have a Maven test project. In which I use context-related tests. I use a
> maven-surefire-plugin to run tests. I need to make the test stop running
> after the first failed test. I found a way to do this through
> -Dsurefire.skipAfterFailureCount=1, but it doesn't work. Maybe I'm doing
> something wrong? Below is my pom.xml:
> {code:java}
>
> 5.3.0
> 5.5.1
> 3.141.59
> 2.12.1
> 1.8.10
> 3.0.0-M3
> 1.5.2
> 5.5.2
> 5.5.2
> 2.10.0
> 1.8
> 1.8
> UTF-8
> UTF-8
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> ${maven.surefire.plugin.version}
>
>
> -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
> -Dsurefire.skipAfterFailureCount=1
>
>
>
> allure.results.directory
>
> ${project.build.directory}/allure-results
>
>
>
>
>
>
> {code}
> Also I tried this option:
> {code:java}
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> ${maven.surefire.plugin.version}
>
> 1
>
> -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
>
>
> allure.results.directory
>
> ${project.build.directory}/allure-results
>
>
>
>
>
>
> {code}
> Why is this parameter ignored?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
