[jira] [Updated] (MRELEASE-1109) update-versions removes the CI-friendly ${revisions}
[
https://issues.apache.org/jira/browse/MRELEASE-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRELEASE-1109:
--
Fix Version/s: next-release
> update-versions removes the CI-friendly ${revisions}
>
>
> Key: MRELEASE-1109
> URL: https://issues.apache.org/jira/browse/MRELEASE-1109
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare, update-versions
>Affects Versions: 2.5.3, 3.0.0-M7
>Reporter: Marcel Stör
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Given: a project using CI-friendly versions as per
> [https://maven.apache.org/maven-ci-friendly.html]
> {code:xml}
> ${revision}
> ...
>
> 1.0.0-SNAPSHOT
>
> {code}
> If I run {{mvn release:update-versions}} (with or without
> {{{}-DautoVersionSubmodules=true{}}}) I expect the release plugin to change
> the {{$revision}} property. Instead it blindly replaces
> {{${revision}}} with the hard-coded version set on the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755889#comment-17755889
]
Maximilian Novikov commented on MBUILDCACHE-67:
---
>But it's a lie, the build goes straight to the phase where it saves the
>generated artefact in cache.
failed to restore -> normal build -> save the result of normal build - that's
how it's expected to work
are you referring that the normal build is not executed at all? could you
please share the detail of your project structure?
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> 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:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.629 s
> [INFO] Finished at: 2023-08-02T23:21:36+02:00
> [INFO]
> ---
[jira] [Commented] (MSOURCES-143) Can't create a source and test jar in Commons using commons-parent
[
https://issues.apache.org/jira/browse/MSOURCES-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755948#comment-17755948
]
Gary D. Gregory commented on MSOURCES-143:
--
I've decided to save time today so am I forcing {{commons-parent}} to use
{{version.maven-source-plugin}} 3.2.1 on Java 8.
Thank you all for your time.
> Can't create a source and test jar in Commons using commons-parent
> --
>
> Key: MSOURCES-143
> URL: https://issues.apache.org/jira/browse/MSOURCES-143
> Project: Maven Source Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Gary D. Gregory
>Priority: Major
>
> Steps to reproduce:
> # git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> # cd commons-parent
> # git checkout 8d886ce8382f7a79f06d51a3afc386b8a37d0473
> # mvn clean install
> # cd ..
> # git clone https://gitbox.apache.org/repos/asf/commons-cli.git
> # cd commons-cli
> # git checkout 08f8c5034a8492be6db65b2086341c292489ee53
> # mvn clean package
> [INFO] --- source:3.3.0:jar-no-fork (create-source-jar) @ commons-cli ---
> [ERROR] We have duplicated artifacts attached.
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 15.233 s
> [INFO] Finished at: 2023-08-15T15:39:45-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork
> (create-source-jar) on project commons-cli: Presumably you have configured
> maven-source-plugn to execute twice times in your build. You have to
> configure a classifier for at least on of them. -> [Help 1]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755955#comment-17755955
]
Kevin Buntrock commented on MBUILDCACHE-67:
---
> are you referring that the normal build is not executed at all? could you
> please share the detail of your project structure?
Yes, exactly. My project structure is not relevant since my encounter with the
issue was due to a development mistake I did on a private branch while
exploring some improvement ideas on the "attachedOutputs" functionality (my
code threw a NullPointerException).
You can do the same on a branch to reproduce the bug : throw arbitrarily an
exception in a method involved in the restore functionality : the exception is
well caught, there is a log saying that the normal build will be executed
("Cannot restore project artifacts, continuing with non cached build").
And then the build goes straight to the "save in cache" phase, which saves a
falsy build. Cf the first log entry of the issue
Anyway, even if I discovered the issue artificially, there are/will be some
natural ways to throw an error in the restoration phase (ex : a broken pipe
with the remote cache).
Later, in order to reproduce the error on a clean branch dedicated to this fix,
I tried to manually delete a cached artefact on my filesystem.
And discovered that the default "non lazy" functionality of the artefact
restoration is actually half implemented (second part of the issue).
Since you are interested in the problem, could you have a look at the attached
fix I submitted? It's in draft only for a utility method used in the IT test
(waiting for another pending PR to factorize it).
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.Na
[GitHub] [maven-build-cache-extension] maximilian-novikov-db commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
maximilian-novikov-db commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1298686503
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
perhaps we need to execute all mojos in this case including for Clean phase
to remove any "garbage" which could left after an unsuccessful restore
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756066#comment-17756066
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
maximilian-novikov-db commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1298686503
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
perhaps we need to execute all mojos in this case including for Clean phase
to remove any "garbage" which could left after an unsuccessful restore
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> 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:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m
[GitHub] [maven-build-cache-extension] maximilian-novikov-db commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
maximilian-novikov-db commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1298686503
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
perhaps we need to execute all mojos in this case including for Clean phase
to remove any "garbage" which could be left after an unsuccessful restore
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756068#comment-17756068
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
maximilian-novikov-db commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1298686503
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
perhaps we need to execute all mojos in this case including for Clean phase
to remove any "garbage" which could be left after an unsuccessful restore
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> 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:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #92: [MBUILDCACHE-67] Bugfix artefact restoration error not handled properly
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1298710444
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
Hi Kevin. Please elaborate, what are the benefits of implementing this.
Because drawbacks are apparent - cached artifacts not used in the actual build
might fail the build now (exotic classifiers, etc.). If that starts happening,
it is a more serious issue than a delayed error.
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
Review Comment:
Looks like a more relevant name for the original intent is `lazyDownload`.
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
Good point. Restoring in the tmp + mv seems like a more robust approach.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756089#comment-17756089
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1298710444
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
Hi Kevin. Please elaborate, what are the benefits of implementing this.
Because drawbacks are apparent - cached artifacts not used in the actual build
might fail the build now (exotic classifiers, etc.). If that starts happening,
it is a more serious issue than a delayed error.
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
Review Comment:
Looks like a more relevant name for the original intent is `lazyDownload`.
##
src/main/java/org/apache/maven/buildcache/BuildCacheMojosExecutionStrategy.java:
##
@@ -129,7 +129,8 @@ public void execute(
boolean restored = result.isSuccess(); // if partially restored
need to save increment
if (restorable) {
restored &= restoreProject(result, mojoExecutions,
mojoExecutionRunner, cacheConfig);
-} else {
+}
+if (!restored) {
Review Comment:
Good point. Restoring in the tmp + mv seems like a more robust approach.
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.Nat
[jira] [Commented] (MBUILDCACHE-67) Any error in restoring from the cache should resume the non cache build
[
https://issues.apache.org/jira/browse/MBUILDCACHE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756091#comment-17756091
]
ASF GitHub Bot commented on MBUILDCACHE-67:
---
AlexanderAshitkin commented on code in PR #92:
URL:
https://github.com/apache/maven-build-cache-extension/pull/92#discussion_r1298710444
##
src/main/java/org/apache/maven/buildcache/CacheControllerImpl.java:
##
@@ -401,6 +399,26 @@ private Future createDownloadTask(
});
if (!cacheConfig.isLazyRestore()) {
downloadTask.run();
+try {
+downloadTask.get();
Review Comment:
Hi Kevin. Please elaborate, what are the benefits of implementing this.
Because drawbacks are apparent - cached artifacts not used in the actual build
might fail the build now (exotic classifiers, etc.). If that starts happening,
it is a more serious issue than a delayed error. The change has its own merits,
but the default behavior should be the most reasonable considering all the
cases.
> Any error in restoring from the cache should resume the non cache build
> ---
>
> Key: MBUILDCACHE-67
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-67
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Kevin Buntrock
>Priority: Major
> Labels: pull-request-available
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> 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:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> [INFO] Cannot restore project artifacts, co
[jira] [Created] (SUREFIRE-2190) optional dependencies and JPMS modules confuse surefire
Henning Schmiedehausen created SUREFIRE-2190:
Summary: optional dependencies and JPMS modules confuse surefire
Key: SUREFIRE-2190
URL: https://issues.apache.org/jira/browse/SUREFIRE-2190
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support, Maven Surefire Plugin
Affects Versions: 3.1.2
Reporter: Henning Schmiedehausen
The surefire plugin, when executing tests for JPMS code, patches the test code
"into" the module under test (using {{--patch-module}}). This work for
compile+runtime dependencies (`requires`) but not for compile required/runtime
optional dependencies ({{requires static}}).
The plugin only adds the module under test using {{--module
module.under.test.id}} to the JVM that is executing the test classes. As
{{requires static}} dependencies are not loaded transitively, any dependency
that is optional for the main artifact but required for test code is not found.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2190) optional dependencies and JPMS modules confuse surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated SUREFIRE-2190:
-
Description:
The surefire plugin, when executing tests for JPMS code, patches the test code
"into" the module under test (using {{{}--patch-module{}}}). This work for
compile+runtime dependencies (`requires`) but not for compile required/runtime
optional dependencies ({{{}requires static{}}}).
The plugin only adds the module under test using {{--add-modules
module.under.test.id}} to the JVM that is executing the test classes. As
{{requires static}} dependencies are not loaded transitively, any dependency
that is optional for the main artifact but required for test code is not found.
clone and build the test repo: [https://github.com/hgschmie/msurefire2190]
This repo contains three artifacts with identical code:
thing1 builds a main artifact without JPMS
thing2 builds a main artifact with a strong ({{{}requires{}}}) dependency on
jakarta.annotation.
thing3 builds a main artifact with a compile-only ({{requires static}})
dependency on jakarta.annotation.
The code and its test classes are otherwise identical.
Running {{mvn -DskipTests}} clean install builds all three modules and the test
code.
Running {{mvn surefire:test}} passes the tests in the first two modules but
fails in the third.
Explanation:
The surefire plugin, when it executes tests using JPMS adds all referenced
modules to the module path (in this case the module under test itself and the
jakarta.annotations-api jar). It then adds the main module using
{{--add-modules}} and patches this module with the test classes (using
{{{}-patch-module{}}}, so that the test classes execute as part of the module.
In case of a compile+runtime ({{requires}}) relationship, the JVM will find the
required JPMS module on the module path and add it as accessible. This is why
the "thing2" tests pass.
In case of a compile only/runtime optional ({{requires static}}) relationship,
the JVM will not add the module transitively as it is considered a
compilation-only dependency. For the code under test to be able to access the
classes from jakarta.annotation, they must be declared as a module. However,
the test code only adds the module under test with {{--add-modules}}. So the
test classes do not find any classes from the jakarta.annotation module and the
test fails.
The fix is simple: Instead of just adding the module under test using
{{--add-modules}}, the surefire plugin should use {{-add-modules
ALL-MODULE-PATH}}.
Which is correct, because the code is not looking for compile time only
dependencies but actual runtime dependencies where the code under execution may
also need to access optional runtime dependencies (see
[https://nipafx.dev/java-modules-optional-dependencies/] for a slightly longer
explanation).
was:
The surefire plugin, when executing tests for JPMS code, patches the test code
"into" the module under test (using {{--patch-module}}). This work for
compile+runtime dependencies (`requires`) but not for compile required/runtime
optional dependencies ({{requires static}}).
The plugin only adds the module under test using {{--module
module.under.test.id}} to the JVM that is executing the test classes. As
{{requires static}} dependencies are not loaded transitively, any dependency
that is optional for the main artifact but required for test code is not found.
> optional dependencies and JPMS modules confuse surefire
> ---
>
> Key: SUREFIRE-2190
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2190
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.1.2
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> The surefire plugin, when executing tests for JPMS code, patches the test
> code "into" the module under test (using {{{}--patch-module{}}}). This work
> for compile+runtime dependencies (`requires`) but not for compile
> required/runtime optional dependencies ({{{}requires static{}}}).
> The plugin only adds the module under test using {{--add-modules
> module.under.test.id}} to the JVM that is executing the test classes. As
> {{requires static}} dependencies are not loaded transitively, any dependency
> that is optional for the main artifact but required for test code is not
> found.
> clone and build the test repo: [https://github.com/hgschmie/msurefire2190]
> This repo contains three artifacts with identical code:
> thing1 builds a main artifact without JPMS
> thing2 builds a main artifact with a strong ({{{}requires{}}}) dependency on
> jakarta.annotation.
> thing3 builds a main artifact with a compile-only ({{requires static}})
> dependency on jakarta.annotati
[jira] [Commented] (SUREFIRE-2190) optional dependencies and JPMS modules confuse surefire
[
https://issues.apache.org/jira/browse/SUREFIRE-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756238#comment-17756238
]
ASF GitHub Bot commented on SUREFIRE-2190:
--
hgschmie opened a new pull request, #668:
URL: https://github.com/apache/maven-surefire/pull/668
Include all modules on the module path to the root modules. This fixes
test code that uses dependencies that are declared as optional
(`require static`) for the main artifact to access these dependencies.
maven surefire plugin struggles with optional dependencies for the main
artifact and test code.
Check out the test repo at https://github.com/hgschmie/msurefire2190
This repo contains three artifacts with identical code:
- thing1 builds a main artifact without JPMS
- thing2 builds a main artifact with a strong (`requires`) dependency on
jakarta.annotation.
- thing3 builds a main artifact with a compile-only (`requires static`)
dependency on jakarta annotations.
The code and its test classes are otherwise identical.
Running `mvn -DskipTests clean install` builds all three modules and the
test code.
Running `mvn surefire:test` passes the tests in the first two modules but
fails in the third.
The surefire plugin, when it executes tests using JPMS adds all
referenced modules to the module path (in this case the module under
test itself and the jakarta.annotations-api jar). It then adds the
main module using `--add-modules` and patches this module with the
test classes (so that the test classes execute as part of the module).
In case of a `requires` relationship, the JVM will find the required
JPMS module and add it as accessible. This is why the "thing2" tests
pass.
In case of a `requires static` relationship, the JVM will not add the
module transitively as it is considered a compilation-only
dependency. For the code under test to be able to access the classes
from `jakarta.annotation`, they must be declared as a module. However,
the test code only adds the module under test with `--add-modules`.
The fix for this is pretty simple but must be done in the surefire
plugin. Instead of adding `--add-modules <... module id under test..>`,
it needs to add `--add-modules ALL-MODULE-PATH`. Which is
correct, because the code is not looking for compile time only
dependencies but actual runtime dependencies where the code under
execution may also need to access optional runtime dependencies (see
https://nipafx.dev/java-modules-optional-dependencies/ for a slightly
longer explanation).
Following this checklist to help us incorporate your
contribution quickly and easily:
- [X] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/SUREFIRE) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [X] Each commit in the pull request should have a meaningful subject line
and body.
- [X] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `SUREFIRE-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [X] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [X] Run `mvn clean install` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [X] You have run the integration tests successfully (`mvn -Prun-its clean
install`).
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [X] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
> optional dependencies and JPMS modules confuse surefire
> ---
>
> Key: SUREFIRE-2190
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2190
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.1.2
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> The surefire plugin, when executing tests for JPMS code, patches the test
> code "into" the module under test (using {{{}--patch-module{}}}). This work
> for compile+runtime dependencies (`req
[GitHub] [maven-surefire] hgschmie opened a new pull request, #668: [SUREFIRE-2190] Fix module dependencies for compile only dependencies
hgschmie opened a new pull request, #668: URL: https://github.com/apache/maven-surefire/pull/668 Include all modules on the module path to the root modules. This fixes test code that uses dependencies that are declared as optional (`require static`) for the main artifact to access these dependencies. maven surefire plugin struggles with optional dependencies for the main artifact and test code. Check out the test repo at https://github.com/hgschmie/msurefire2190 This repo contains three artifacts with identical code: - thing1 builds a main artifact without JPMS - thing2 builds a main artifact with a strong (`requires`) dependency on jakarta.annotation. - thing3 builds a main artifact with a compile-only (`requires static`) dependency on jakarta annotations. The code and its test classes are otherwise identical. Running `mvn -DskipTests clean install` builds all three modules and the test code. Running `mvn surefire:test` passes the tests in the first two modules but fails in the third. The surefire plugin, when it executes tests using JPMS adds all referenced modules to the module path (in this case the module under test itself and the jakarta.annotations-api jar). It then adds the main module using `--add-modules` and patches this module with the test classes (so that the test classes execute as part of the module). In case of a `requires` relationship, the JVM will find the required JPMS module and add it as accessible. This is why the "thing2" tests pass. In case of a `requires static` relationship, the JVM will not add the module transitively as it is considered a compilation-only dependency. For the code under test to be able to access the classes from `jakarta.annotation`, they must be declared as a module. However, the test code only adds the module under test with `--add-modules`. The fix for this is pretty simple but must be done in the surefire plugin. Instead of adding `--add-modules <... module id under test..>`, it needs to add `--add-modules ALL-MODULE-PATH`. Which is correct, because the code is not looking for compile time only dependencies but actual runtime dependencies where the code under execution may also need to access optional runtime dependencies (see https://nipafx.dev/java-modules-optional-dependencies/ for a slightly longer explanation). Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean install`). To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
