[GitHub] [maven-build-cache-extension] maximilian-novikov-db commented on pull request #91: [MBUILDCACHE-64] Exclusion mechanism bugfix
maximilian-novikov-db commented on PR #91: URL: https://github.com/apache/maven-build-cache-extension/pull/91#issuecomment-1685792860 > Changed the exclude mechanism to use path matchers. A bit more than a bugfix now, feedbacks appreciated if you see any lack, implementation detail you disagree with or extra test case to add. @kbuntrock nicely done, it would be useful to update the sample config as well https://github.com/apache/maven-build-cache-extension/blob/master/src/site/resources/maven-build-cache-config.xml -- 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-64) Apply global exclusions to folder names
[
https://issues.apache.org/jira/browse/MBUILDCACHE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756704#comment-17756704
]
ASF GitHub Bot commented on MBUILDCACHE-64:
---
maximilian-novikov-db commented on PR #91:
URL:
https://github.com/apache/maven-build-cache-extension/pull/91#issuecomment-1685792860
> Changed the exclude mechanism to use path matchers. A bit more than a
bugfix now, feedbacks appreciated if you see any lack, implementation detail
you disagree with or extra test case to add.
@kbuntrock nicely done, it would be useful to update the sample config as
well
https://github.com/apache/maven-build-cache-extension/blob/master/src/site/resources/maven-build-cache-config.xml
> Apply global exclusions to folder names
> ---
>
> Key: MBUILDCACHE-64
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-64
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Frank Wagner
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.1.0
>
>
> It is currently not possible to exclude folders by their name, like
> {quote}
>
>
> node_modules
> dist
> build
>
>
> ...
> {quote}
> That's because isFilteredOutSubpath(),
> [https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L638,]
> uses startWith on normalized absolute paths.
> That function could be enhanced with an additional criterion like in
> [https://github.com/apache/maven-build-cache-extension/blob/master/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L510]
> {{filteredOutPaths.stream().anyMatch(it ->
> it.getFileName().equals(entry.getFileName()))}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-doxia] dependabot[bot] opened a new pull request, #174: Bump org.apache.ant:ant-apache-regexp from 1.10.13 to 1.10.14
dependabot[bot] opened a new pull request, #174: URL: https://github.com/apache/maven-doxia/pull/174 Bumps org.apache.ant:ant-apache-regexp from 1.10.13 to 1.10.14. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[GitHub] [maven-plugin-tools] dependabot[bot] opened a new pull request, #223: Bump antVersion from 1.10.13 to 1.10.14
dependabot[bot] opened a new pull request, #223: URL: https://github.com/apache/maven-plugin-tools/pull/223 Bumps `antVersion` from 1.10.13 to 1.10.14. Updates `org.apache.ant:ant` from 1.10.13 to 1.10.14 Updates `org.apache.ant:ant-launcher` from 1.10.13 to 1.10.14 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[GitHub] [maven-antrun-plugin] dependabot[bot] opened a new pull request, #87: Bump org.apache.ant:ant from 1.10.13 to 1.10.14
dependabot[bot] opened a new pull request, #87: URL: https://github.com/apache/maven-antrun-plugin/pull/87 Bumps org.apache.ant:ant from 1.10.13 to 1.10.14. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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] [Created] (MNG-7862) The ModelLocator should always be used when locating pom.xml
Guillaume Nodet created MNG-7862: Summary: The ModelLocator should always be used when locating pom.xml Key: MNG-7862 URL: https://issues.apache.org/jira/browse/MNG-7862 Project: Maven Issue Type: Improvement Affects Versions: 4.0.0-alpha-7 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 4.0.0-alpha-8 There are a few places where the pom.xml location is hardcoded. There's a known interface to locate those, so those references should be cleaned. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7862) The ModelLocator should always be used when locating pom.xml
[ https://issues.apache.org/jira/browse/MNG-7862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756926#comment-17756926 ] ASF GitHub Bot commented on MNG-7862: - gnodet opened a new pull request, #1217: URL: https://github.com/apache/maven/pull/1217 JIRA issue: https://issues.apache.org/jira/browse/MNG-7862 > The ModelLocator should always be used when locating pom.xml > > > Key: MNG-7862 > URL: https://issues.apache.org/jira/browse/MNG-7862 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-7 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-8 > > > There are a few places where the pom.xml location is hardcoded. There's a > known interface to locate those, so those references should be cleaned. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] gnodet opened a new pull request, #289: [MNG-7862] Fix IT
gnodet opened a new pull request, #289: URL: https://github.com/apache/maven-integration-testing/pull/289 (no comment) -- 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
[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_r1300166046
##
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. The main question is whether or not to fail the cache when unused (in
reactor) artifacts cannot be downloaded. I’m trying to understand what are the
benefits of failing the cache. Does it solve any issues? Because in terms of
hit rate, this change brings regression.
--
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=17756943#comment-17756943
]
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_r1300166046
##
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. The main question is whether or not to fail the cache when unused (in
reactor) artifacts cannot be downloaded. I’m trying to understand what are the
benefits of failing the cache. Does it solve any issues? Because in terms of
hit rate, this change brings regression.
> 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.kbun
[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_r1300166046
##
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. The main question is whether or not to fail the cache when unused (in
reactor) artifacts cannot be downloaded. I’m trying to understand what are the
benefits of failing the cache. Does it solve any practical issues? Because in
terms of hit rate, this change brings regression.
--
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=17756944#comment-17756944
]
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_r1300166046
##
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. The main question is whether or not to fail the cache when unused (in
reactor) artifacts cannot be downloaded. I’m trying to understand what are the
benefits of failing the cache. Does it solve any practical issues? Because in
terms of hit rate, this change brings regression.
> 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.g
[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_r1300186078
##
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:
That is discussable:
* `clean` phase has been completed by this time, and repeating it sounds
slightly off to me.
* Keeping partially restored artifacts is error-prone, and `clean` might not
even be requested.
* invoking ad-hoc `clean` might wipe out other cached data and might be
undesirable
It is better to leave it as is and rely on the regular `clean`, or implement
`mv` logic to minimize the risk of corrupted cache data in the target dir.
--
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=17756949#comment-17756949
]
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_r1300186078
##
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:
That is discussable:
* `clean` phase has been completed by this time, and repeating it sounds
slightly off to me.
* Keeping partially restored artifacts is error-prone, and `clean` might not
even be requested.
* invoking ad-hoc `clean` might wipe out other cached data and might be
undesirable
It is better to leave it as is and rely on the regular `clean`, or implement
`mv` logic to minimize the risk of corrupted cache data in the target dir.
> 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)
>
[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_r1300186078
##
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:
That is discussable:
* `clean` phase has been completed by this time, and repeating it sounds
slightly off to me.
* Keeping partially restored artifacts is error-prone, and `clean` might not
even be requested.
* invoking ad-hoc `clean` might wipe out other cached data and might be
undesirable
I see 2 options here: leave it as is (and rely on the user requested
`clean`), or implement `mv` logic to minimize the risk of corrupted cache data
in the target dir.
--
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=17756950#comment-17756950
]
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_r1300186078
##
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:
That is discussable:
* `clean` phase has been completed by this time, and repeating it sounds
slightly off to me.
* Keeping partially restored artifacts is error-prone, and `clean` might not
even be requested.
* invoking ad-hoc `clean` might wipe out other cached data and might be
undesirable
I see 2 options here: leave it as is (and rely on the user requested
`clean`), or implement `mv` logic to minimize the risk of corrupted cache data
in the target dir.
> 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.
[jira] [Created] (MANTRUN-240) Update ant from 1.10.13 to 1.10.14
Sylwester Lachiewicz created MANTRUN-240: Summary: Update ant from 1.10.13 to 1.10.14 Key: MANTRUN-240 URL: https://issues.apache.org/jira/browse/MANTRUN-240 Project: Maven Antrun Plugin Issue Type: Dependency upgrade Reporter: Sylwester Lachiewicz Fix For: 3.2.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MANTRUN-240) Update ant from 1.10.13 to 1.10.14
[ https://issues.apache.org/jira/browse/MANTRUN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MANTRUN-240: - Description: Release Notes of Apache Ant 1.10.14 Changes from Ant 1.10.13 TO Ant 1.10.14 === Changes that could break older environments: --- * Resource#compareTo now invokes getName rather than toString as the later may be costly (for example in the case of a StringResource). Bugzilla Report 66496 * When using Java 18 or higher, Ant will no longer use Java SecurityManager because it has been deprecated for removal and by default is disallowed to be set at runtime [https://openjdk.org/jeps/411]. This will mean that the "" type is no longer functional when using Java 18 or higher. Furthermore, when using Java 18 or higher, if the build executes tasks that call "java.lang.System.exit()" and if those tasks aren't running in a forked VM of their own, then such tasks will now kill the entire Ant build process. It is recommended that such tasks be updated to launch in a forked JVM so that the System.exit() call will not impact the JVM in which Ant process runs. Fixed bugs: --- * log only the stylesheet name in the xslt task. Github Pull Request #199 * junitlauncher task's "test" and "listener" elements which take a "outputDir" property were incorrectly resolving the outputDir against the current working directory instead of the project's basedir. This has now been fixed. Bugzilla Report 66504 * regexmapper would, in some cases, incorrectly consume backslash characters from the "to" attribute, resulting in missing backslashes in the output. This is now fixed. Bugzilla Report 66468 * , and now try to preserve the file permissions of the files they modify. Bugzilla Report 66522 * junitlauncher task would fail if a forked test timed out even if haltOnFailure was set to false. This is now fixed. Bugzilla Report 66411 * fixes a bug in org.apache.tools.zip.ZipOutputStream where, even when "zip64Mode" is set to "always", ZipOutputStream may not create a CEN extra field data for the entry. Bugzilla Report 66873 * legacy-xml listener of junitlauncher task wouldn't report certain failures involving junit jupiter dynamic tests. This has now been fixed. Github Pull Request #122 * allow.class which was introduced in Ant 1.10.13 release, has been removed from this 1.10.14 release. This class was introduced in context of the SecurityManager changes in Ant 1.10.13, which have now been reverted in Ant 1.10.14, since they caused several regressions. Bugzilla Reports 66828, 66951 Other changes: -- * element of the junitlauncher task now has a new optional "java" attribute which can be used to point to a different Java installation for runnning the forked tests. Bugzilla Report 66464 * made sure sorts the echoed properties on JDK9+ as well. Bugzilla Report 66588 * org.apache.tools.ant.taskdefs.Recorder class now introduces a setLogLevel(LogLevel level) method. Bugzilla Report 66238 * The element of junitlaunchertask now allows a "forkMode" attribute. forkMode=perTestClass can now be used to launch each test class in a separate forked JVM. Bugzilla Report 65176 > Update ant from 1.10.13 to 1.10.14 > -- > > Key: MANTRUN-240 > URL: https://issues.apache.org/jira/browse/MANTRUN-240 > Project: Maven Antrun Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > > Release Notes of Apache Ant 1.10.14 > Changes from Ant 1.10.13 TO Ant 1.10.14 > === > Changes that could break older environments: > --- > * Resource#compareTo now invokes getName rather than toString as the > later may be costly (for example in the case of a StringResource). > Bugzilla Report 66496 > * When using Java 18 or higher, Ant will no longer use Java SecurityManager > because it has been deprecated for removal and by default is disallowed > to be set at runtime [https://openjdk.org/jeps/411]. > This will mean that the "" type is no longer functional when > using Java 18 or higher. > Furthermore, when using Java 18 or higher, if the build executes > tasks that call "java.lang.System.exit()" and if those tasks aren't > running in a forked VM of their own, then such tasks will now kill > the entire Ant build process. It is recommended that such tasks be > updated to launch in a forked JVM so that the System.exit() call > will not impact the JVM in which Ant process runs. > Fixed bugs: > --- > * log only the stylesheet name in the xslt task. > Github Pull Request #199 > * junitlauncher task's "test" and "listener" elements which take > a "outputDir" property were incorrec
[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_r1300380821
##
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:
> * Keeping partially restored artifacts is error-prone, and `clean` might
not even be requested.
all mojos except clean are executed again if it falls back to the "normal"
build, i'd say keeping any partially restored data is harmful and may lead to
unpredictable result
--
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
[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_r1300380821
##
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:
> * Keeping partially restored artifacts is error-prone, and `clean` might
not even be requested.
all mojos except clean are executed again, if it falls back to the "normal"
build, i'd say keeping any partially restored data is harmful and may lead to
unpredictable result
--
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=17757012#comment-17757012
]
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_r1300380821
##
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:
> * Keeping partially restored artifacts is error-prone, and `clean` might
not even be requested.
all mojos except clean are executed again if it falls back to the "normal"
build, i'd say keeping any partially restored data is harmful and may lead to
unpredictable result
> 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)
>
[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=17757015#comment-17757015
]
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_r1300380821
##
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:
> * Keeping partially restored artifacts is error-prone, and `clean` might
not even be requested.
all mojos except clean are executed again, if it falls back to the "normal"
build, i'd say keeping any partially restored data is harmful and may lead to
unpredictable result
> 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)
>
[jira] [Assigned] (MANTRUN-240) Update ant from 1.10.13 to 1.10.14
[ https://issues.apache.org/jira/browse/MANTRUN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MANTRUN-240: Assignee: Sylwester Lachiewicz > Update ant from 1.10.13 to 1.10.14 > -- > > Key: MANTRUN-240 > URL: https://issues.apache.org/jira/browse/MANTRUN-240 > Project: Maven Antrun Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > > Release Notes of Apache Ant 1.10.14 > Changes from Ant 1.10.13 TO Ant 1.10.14 > === > Changes that could break older environments: > --- > * Resource#compareTo now invokes getName rather than toString as the > later may be costly (for example in the case of a StringResource). > Bugzilla Report 66496 > * When using Java 18 or higher, Ant will no longer use Java SecurityManager > because it has been deprecated for removal and by default is disallowed > to be set at runtime [https://openjdk.org/jeps/411]. > This will mean that the "" type is no longer functional when > using Java 18 or higher. > Furthermore, when using Java 18 or higher, if the build executes > tasks that call "java.lang.System.exit()" and if those tasks aren't > running in a forked VM of their own, then such tasks will now kill > the entire Ant build process. It is recommended that such tasks be > updated to launch in a forked JVM so that the System.exit() call > will not impact the JVM in which Ant process runs. > Fixed bugs: > --- > * log only the stylesheet name in the xslt task. > Github Pull Request #199 > * junitlauncher task's "test" and "listener" elements which take > a "outputDir" property were incorrectly resolving the outputDir > against the current working directory instead of the project's > basedir. This has now been fixed. > Bugzilla Report 66504 > * regexmapper would, in some cases, incorrectly consume backslash characters > from the "to" attribute, resulting in missing backslashes in the output. > This is now fixed. > Bugzilla Report 66468 > * , and now try to preserve the > file permissions of the files they modify. > Bugzilla Report 66522 > * junitlauncher task would fail if a forked test timed out even > if haltOnFailure was set to false. This is now fixed. > Bugzilla Report 66411 > * fixes a bug in org.apache.tools.zip.ZipOutputStream where, even > when "zip64Mode" is set to "always", ZipOutputStream may not create > a CEN extra field data for the entry. > Bugzilla Report 66873 > * legacy-xml listener of junitlauncher task wouldn't report certain > failures involving junit jupiter dynamic tests. This has now been > fixed. > Github Pull Request #122 > * allow.class which was introduced in Ant 1.10.13 release, has been > removed from this 1.10.14 release. This class was introduced in > context of the SecurityManager changes in Ant 1.10.13, which have > now been reverted in Ant 1.10.14, since they caused several > regressions. > Bugzilla Reports 66828, 66951 > Other changes: > -- > * element of the junitlauncher task now has a new optional "java" > attribute which can be used to point to a different Java installation > for runnning the forked tests. > Bugzilla Report 66464 > * made sure sorts the echoed properties on JDK9+ as well. > Bugzilla Report 66588 > * org.apache.tools.ant.taskdefs.Recorder class now introduces a > setLogLevel(LogLevel level) method. > Bugzilla Report 66238 > * The element of junitlaunchertask now allows a "forkMode" > attribute. forkMode=perTestClass can now be used to launch > each test class in a separate forked JVM. > Bugzilla Report 65176 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MANTRUN-240) Update ant from 1.10.13 to 1.10.14
[ https://issues.apache.org/jira/browse/MANTRUN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MANTRUN-240. Resolution: Fixed > Update ant from 1.10.13 to 1.10.14 > -- > > Key: MANTRUN-240 > URL: https://issues.apache.org/jira/browse/MANTRUN-240 > Project: Maven Antrun Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > > Release Notes of Apache Ant 1.10.14 > Changes from Ant 1.10.13 TO Ant 1.10.14 > === > Changes that could break older environments: > --- > * Resource#compareTo now invokes getName rather than toString as the > later may be costly (for example in the case of a StringResource). > Bugzilla Report 66496 > * When using Java 18 or higher, Ant will no longer use Java SecurityManager > because it has been deprecated for removal and by default is disallowed > to be set at runtime [https://openjdk.org/jeps/411]. > This will mean that the "" type is no longer functional when > using Java 18 or higher. > Furthermore, when using Java 18 or higher, if the build executes > tasks that call "java.lang.System.exit()" and if those tasks aren't > running in a forked VM of their own, then such tasks will now kill > the entire Ant build process. It is recommended that such tasks be > updated to launch in a forked JVM so that the System.exit() call > will not impact the JVM in which Ant process runs. > Fixed bugs: > --- > * log only the stylesheet name in the xslt task. > Github Pull Request #199 > * junitlauncher task's "test" and "listener" elements which take > a "outputDir" property were incorrectly resolving the outputDir > against the current working directory instead of the project's > basedir. This has now been fixed. > Bugzilla Report 66504 > * regexmapper would, in some cases, incorrectly consume backslash characters > from the "to" attribute, resulting in missing backslashes in the output. > This is now fixed. > Bugzilla Report 66468 > * , and now try to preserve the > file permissions of the files they modify. > Bugzilla Report 66522 > * junitlauncher task would fail if a forked test timed out even > if haltOnFailure was set to false. This is now fixed. > Bugzilla Report 66411 > * fixes a bug in org.apache.tools.zip.ZipOutputStream where, even > when "zip64Mode" is set to "always", ZipOutputStream may not create > a CEN extra field data for the entry. > Bugzilla Report 66873 > * legacy-xml listener of junitlauncher task wouldn't report certain > failures involving junit jupiter dynamic tests. This has now been > fixed. > Github Pull Request #122 > * allow.class which was introduced in Ant 1.10.13 release, has been > removed from this 1.10.14 release. This class was introduced in > context of the SecurityManager changes in Ant 1.10.13, which have > now been reverted in Ant 1.10.14, since they caused several > regressions. > Bugzilla Reports 66828, 66951 > Other changes: > -- > * element of the junitlauncher task now has a new optional "java" > attribute which can be used to point to a different Java installation > for runnning the forked tests. > Bugzilla Report 66464 > * made sure sorts the echoed properties on JDK9+ as well. > Bugzilla Report 66588 > * org.apache.tools.ant.taskdefs.Recorder class now introduces a > setLogLevel(LogLevel level) method. > Bugzilla Report 66238 > * The element of junitlaunchertask now allows a "forkMode" > attribute. forkMode=perTestClass can now be used to launch > each test class in a separate forked JVM. > Bugzilla Report 65176 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MANTRUN-240) Update ant from 1.10.13 to 1.10.14
[ https://issues.apache.org/jira/browse/MANTRUN-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757027#comment-17757027 ] ASF GitHub Bot commented on MANTRUN-240: slachiewicz merged PR #87: URL: https://github.com/apache/maven-antrun-plugin/pull/87 > Update ant from 1.10.13 to 1.10.14 > -- > > Key: MANTRUN-240 > URL: https://issues.apache.org/jira/browse/MANTRUN-240 > Project: Maven Antrun Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > > Release Notes of Apache Ant 1.10.14 > Changes from Ant 1.10.13 TO Ant 1.10.14 > === > Changes that could break older environments: > --- > * Resource#compareTo now invokes getName rather than toString as the > later may be costly (for example in the case of a StringResource). > Bugzilla Report 66496 > * When using Java 18 or higher, Ant will no longer use Java SecurityManager > because it has been deprecated for removal and by default is disallowed > to be set at runtime [https://openjdk.org/jeps/411]. > This will mean that the "" type is no longer functional when > using Java 18 or higher. > Furthermore, when using Java 18 or higher, if the build executes > tasks that call "java.lang.System.exit()" and if those tasks aren't > running in a forked VM of their own, then such tasks will now kill > the entire Ant build process. It is recommended that such tasks be > updated to launch in a forked JVM so that the System.exit() call > will not impact the JVM in which Ant process runs. > Fixed bugs: > --- > * log only the stylesheet name in the xslt task. > Github Pull Request #199 > * junitlauncher task's "test" and "listener" elements which take > a "outputDir" property were incorrectly resolving the outputDir > against the current working directory instead of the project's > basedir. This has now been fixed. > Bugzilla Report 66504 > * regexmapper would, in some cases, incorrectly consume backslash characters > from the "to" attribute, resulting in missing backslashes in the output. > This is now fixed. > Bugzilla Report 66468 > * , and now try to preserve the > file permissions of the files they modify. > Bugzilla Report 66522 > * junitlauncher task would fail if a forked test timed out even > if haltOnFailure was set to false. This is now fixed. > Bugzilla Report 66411 > * fixes a bug in org.apache.tools.zip.ZipOutputStream where, even > when "zip64Mode" is set to "always", ZipOutputStream may not create > a CEN extra field data for the entry. > Bugzilla Report 66873 > * legacy-xml listener of junitlauncher task wouldn't report certain > failures involving junit jupiter dynamic tests. This has now been > fixed. > Github Pull Request #122 > * allow.class which was introduced in Ant 1.10.13 release, has been > removed from this 1.10.14 release. This class was introduced in > context of the SecurityManager changes in Ant 1.10.13, which have > now been reverted in Ant 1.10.14, since they caused several > regressions. > Bugzilla Reports 66828, 66951 > Other changes: > -- > * element of the junitlauncher task now has a new optional "java" > attribute which can be used to point to a different Java installation > for runnning the forked tests. > Bugzilla Report 66464 > * made sure sorts the echoed properties on JDK9+ as well. > Bugzilla Report 66588 > * org.apache.tools.ant.taskdefs.Recorder class now introduces a > setLogLevel(LogLevel level) method. > Bugzilla Report 66238 > * The element of junitlaunchertask now allows a "forkMode" > attribute. forkMode=perTestClass can now be used to launch > each test class in a separate forked JVM. > Bugzilla Report 65176 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-antrun-plugin] dependabot[bot] closed pull request #47: Bump ant from 1.10.10 to 1.10.11 in /src/it/filesets-test
dependabot[bot] closed pull request #47: Bump ant from 1.10.10 to 1.10.11 in /src/it/filesets-test URL: https://github.com/apache/maven-antrun-plugin/pull/47 -- 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
[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_r1300432092
##
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:
I meant that the `clean` might not be requested by the user. In that case,
using the `clean` looks undesirable because it has side effects outside the
cache that might confuse the user. And I agree that leaving partially restored
data is error-prone. But all three options (leaving as is, adding clean, or
moving) have drawbacks.
--
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=17757030#comment-17757030
]
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_r1300432092
##
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:
I meant that the `clean` might not be requested by the user. In that case,
using the `clean` looks undesirable because it has side effects outside the
cache that might confuse the user. And I agree that leaving partially restored
data is error-prone. But all three options (leaving as is, adding clean, or
moving) have drawbacks.
> 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.
[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_r1300166046
##
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. The main question is whether or not to fail the cache when unused (in
reactor) artifacts cannot be downloaded. I’m trying to understand what are the
benefits of failing the cache. Does it solve any practical issues? Because in
terms of the cache hit rate, this change brings regression.
--
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=17757031#comment-17757031
]
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_r1300166046
##
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. The main question is whether or not to fail the cache when unused (in
reactor) artifacts cannot be downloaded. I’m trying to understand what are the
benefits of failing the cache. Does it solve any practical issues? Because in
terms of the cache hit rate, this change brings regression.
> 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-cac
[GitHub] [maven-build-cache-extension] AlexanderAshitkin commented on a diff in pull request #91: [MBUILDCACHE-64] Exclusion mechanism bugfix
AlexanderAshitkin commented on code in PR #91:
URL:
https://github.com/apache/maven-build-cache-extension/pull/91#discussion_r1298793252
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -165,45 +184,94 @@ public MavenProjectInput(
this.repoSystem = repoSystem;
this.remoteCache = remoteCache;
Properties properties = project.getProperties();
-this.dirGlob = properties.getProperty(CACHE_INPUT_GLOB_NAME,
config.getDefaultGlob());
+this.defaultFilenameGlob =
properties.getProperty(CACHE_INPUT_GLOB_NAME, config.getDefaultGlob());
this.processPlugins =
Boolean.parseBoolean(properties.getProperty(CACHE_PROCESS_PLUGINS,
config.isProcessPlugins()));
this.tmpDir = System.getProperty("java.io.tmpdir");
+this.baseDirectoryGlob = baseDirPath.toString().replace("\\", "/") +
"/";
Review Comment:
For consistency, this should probably be normalized to a `/**` format,
or the variable should be renamed `*Path`.
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -165,45 +184,94 @@ public MavenProjectInput(
this.repoSystem = repoSystem;
this.remoteCache = remoteCache;
Properties properties = project.getProperties();
-this.dirGlob = properties.getProperty(CACHE_INPUT_GLOB_NAME,
config.getDefaultGlob());
+this.defaultFilenameGlob =
properties.getProperty(CACHE_INPUT_GLOB_NAME, config.getDefaultGlob());
this.processPlugins =
Boolean.parseBoolean(properties.getProperty(CACHE_PROCESS_PLUGINS,
config.isProcessPlugins()));
this.tmpDir = System.getProperty("java.io.tmpdir");
+this.baseDirectoryGlob = baseDirPath.toString().replace("\\", "/") +
"/";
+
org.apache.maven.model.Build build = project.getBuild();
-filteredOutPaths = new ArrayList<>(Arrays.asList(
-normalizedPath(build.getDirectory()), // target by default
-normalizedPath(build.getOutputDirectory()),
-normalizedPath(build.getTestOutputDirectory(;
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target by default
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getOutputDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target/classes by default
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getTestOutputDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target/test-classes by default
List excludes = config.getGlobalExcludePaths();
for (Exclude excludePath : excludes) {
-filteredOutPaths.add(Paths.get(excludePath.getValue()));
+addToExcludedSection(excludePath.getValue(), true);
}
for (String propertyName : properties.stringPropertyNames()) {
if (propertyName.startsWith(CACHE_EXCLUDE_NAME)) {
String propertyValue = properties.getProperty(propertyName);
-Path path = Paths.get(propertyValue);
-filteredOutPaths.add(path);
+addToExcludedSection(propertyValue, true);
+
if (LOGGER.isDebugEnabled()) {
LOGGER.debug(
-"Adding an excludePath from property '{}', values
is '{}', path is '{}' ",
-propertyName,
-propertyValue,
-path);
+"Adding an excludePath from property '{}', value
is '{}'", propertyName, propertyValue);
}
}
}
CacheUtils.debugPrintCollection(
-LOGGER,
-filteredOutPaths,
-"List of excluded paths (checked either by fileName or by
startsWith prefix)",
-"Path entry");
+LOGGER, inputExcludePathMatcherString, "List of excluded glob
patterns", "Pattern");
this.fileComparator = new PathIgnoringCaseComparator();
}
+private String convertToPathMatcherFileSeperator(String path) {
+return path.replace("\\", "/");
+}
+
+/**
+ * Add a value from the excluded section list to the directories and/or
the filenames ban list.
+ * @param excludedValue a value from the exclude list
+ */
+private void addToExcludedSection(String excludedValue, boolean
addProjectBaseDir) {
+
+String pathMatcherGlob = GLOB_PX
++
+// Add the base
[jira] [Commented] (MBUILDCACHE-64) Apply global exclusions to folder names
[
https://issues.apache.org/jira/browse/MBUILDCACHE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757035#comment-17757035
]
ASF GitHub Bot commented on MBUILDCACHE-64:
---
AlexanderAshitkin commented on code in PR #91:
URL:
https://github.com/apache/maven-build-cache-extension/pull/91#discussion_r1298793252
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -165,45 +184,94 @@ public MavenProjectInput(
this.repoSystem = repoSystem;
this.remoteCache = remoteCache;
Properties properties = project.getProperties();
-this.dirGlob = properties.getProperty(CACHE_INPUT_GLOB_NAME,
config.getDefaultGlob());
+this.defaultFilenameGlob =
properties.getProperty(CACHE_INPUT_GLOB_NAME, config.getDefaultGlob());
this.processPlugins =
Boolean.parseBoolean(properties.getProperty(CACHE_PROCESS_PLUGINS,
config.isProcessPlugins()));
this.tmpDir = System.getProperty("java.io.tmpdir");
+this.baseDirectoryGlob = baseDirPath.toString().replace("\\", "/") +
"/";
Review Comment:
For consistency, this should probably be normalized to a `/**` format,
or the variable should be renamed `*Path`.
##
src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java:
##
@@ -165,45 +184,94 @@ public MavenProjectInput(
this.repoSystem = repoSystem;
this.remoteCache = remoteCache;
Properties properties = project.getProperties();
-this.dirGlob = properties.getProperty(CACHE_INPUT_GLOB_NAME,
config.getDefaultGlob());
+this.defaultFilenameGlob =
properties.getProperty(CACHE_INPUT_GLOB_NAME, config.getDefaultGlob());
this.processPlugins =
Boolean.parseBoolean(properties.getProperty(CACHE_PROCESS_PLUGINS,
config.isProcessPlugins()));
this.tmpDir = System.getProperty("java.io.tmpdir");
+this.baseDirectoryGlob = baseDirPath.toString().replace("\\", "/") +
"/";
+
org.apache.maven.model.Build build = project.getBuild();
-filteredOutPaths = new ArrayList<>(Arrays.asList(
-normalizedPath(build.getDirectory()), // target by default
-normalizedPath(build.getOutputDirectory()),
-normalizedPath(build.getTestOutputDirectory(;
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target by default
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getOutputDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target/classes by default
+addToExcludedSection(
+convertToPathMatcherFileSeperator(
+
normalizedPath(build.getTestOutputDirectory()).toString())
++ GLOB_SX_ALL_SUB_FILES,
+false); // target/test-classes by default
List excludes = config.getGlobalExcludePaths();
for (Exclude excludePath : excludes) {
-filteredOutPaths.add(Paths.get(excludePath.getValue()));
+addToExcludedSection(excludePath.getValue(), true);
}
for (String propertyName : properties.stringPropertyNames()) {
if (propertyName.startsWith(CACHE_EXCLUDE_NAME)) {
String propertyValue = properties.getProperty(propertyName);
-Path path = Paths.get(propertyValue);
-filteredOutPaths.add(path);
+addToExcludedSection(propertyValue, true);
+
if (LOGGER.isDebugEnabled()) {
LOGGER.debug(
-"Adding an excludePath from property '{}', values
is '{}', path is '{}' ",
-propertyName,
-propertyValue,
-path);
+"Adding an excludePath from property '{}', value
is '{}'", propertyName, propertyValue);
}
}
}
CacheUtils.debugPrintCollection(
-LOGGER,
-filteredOutPaths,
-"List of excluded paths (checked either by fileName or by
startsWith prefix)",
-"Path entry");
+LOGGER, inputExcludePathMatcherString, "List of excluded glob
patterns", "Pattern");
this.fileComparator = new PathIgnoringCaseComparator();
}
+private String convertToPathMatcherFileSeperator(String path) {
+return path.replace("\\", "/");
+}
+
+/**
+ * Add a value from the excluded section list to the directories and/or
the filename
[jira] [Commented] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757065#comment-17757065
]
Henning Schmiedehausen commented on MJAVADOC-769:
-
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc plugin tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same was as module source FILENAME (iaw patched into the main
module).
> javadoc plugin can not deal with optional dependencies when building java 9+
> javadocs
> -
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
> -encoding
> 'UTF-8'
> -public
> -quiet
> --release
> 11
> -bottom
> 'Copyright © 2023. All rights reserved.'
> -charset
> 'UTF-8'
> -d
> '/Users/henning/scratch/mjavadoc769/target/apidocs'
> -docencoding
> 'UTF-8'
> -Xdoclint:none
> -doctitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> -linkoffline
> 'https://docs.oracle.com/en/java/javase/11/docs/api'
> '/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
> -nohelp
> -use
> -version
> -windowtitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> {code}
> The javadoc plugin decides that the "javax.inject-1.jar" is added to the
> classpath even though it is an optional dependency of the main module.
> Contrary to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module
> path.
> The reason for this may be that the jakarta module contains a module-info
> (hidden in
[jira] [Comment Edited] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757065#comment-17757065
]
Henning Schmiedehausen edited comment on MJAVADOC-769 at 8/21/23 7:04 PM:
--
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc tool tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same was as module source FILENAME (iaw patched into the main
module).
was (Author: henning):
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc plugin tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same was as module source FILENAME (iaw patched into the main
module).
> javadoc plugin can not deal with optional dependencies when building java 9+
> javadocs
> -
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-99
[jira] [Comment Edited] (MJAVADOC-769) javadoc plugin can not deal with optional dependencies when building java 9+ javadocs
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757065#comment-17757065
]
Henning Schmiedehausen edited comment on MJAVADOC-769 at 8/21/23 7:05 PM:
--
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc tool tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same way as module source FILENAME (iaw patched into the main
module).
was (Author: henning):
having spent some more time debugging this, this is what happens:
- the code depends on com.google.inject.Provider, which in turn extends
javax.inject.Provider
- the google class is in a jar (guice-5.1.0.jar) which has an
Automatic-Module-Name entry
- the javax class is in a jar that does not.
The plugin now pulls the guice jar onto the module path and patches the main
module with the javax.inject jar
But the javadoc tool tries to resolve the class hierarchy of the included
provider, which is the google guice provider (on the module path) and then the
javax provider (patched into the main module, BUT NOT into guice). and the
javadoc tool can not resolve the javax.inject class as parent for guice because
it is not visible in that module.
The solution is IMHO straightforward: instead of treating jars with a module
source of MANIFEST the same way as jars with a module source of
MODULEDESCRIPTOR and different from module source FILENAME, they should be
treated the same was as module source FILENAME (iaw patched into the main
module).
> javadoc plugin can not deal with optional dependencies when building java 9+
> javadocs
> -
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-
[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=17757091#comment-17757091
]
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 cache 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] [Updated] (MJAVADOC-769) javadoc plugin can not deal with transitive filename based modules
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henning Schmiedehausen updated MJAVADOC-769:
Summary: javadoc plugin can not deal with transitive filename based modules
(was: javadoc plugin can not deal with optional dependencies when building
java 9+ javadocs)
> javadoc plugin can not deal with transitive filename based modules
> --
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scratch/mjavadoc769/target/generated-sources/annotations:/Users/henning/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar:/Users/henning/.m2/repository/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar:/Users/henning/.m2/repository/com/google/guava/listenablefuture/.0-empty-to-avoid-conflict-with-guava/listenablefuture-.0-empty-to-avoid-conflict-with-guava.jar:/Users/henning/.m2/repository/com/google/code/findbugs/jsr305/3.0.2/jsr305-3.0.2.jar:/Users/henning/.m2/repository/com/google/j2objc/j2objc-annotations/1.3/j2objc-annotations-1.3.jar:/Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar'
> -encoding
> 'UTF-8'
> -public
> -quiet
> --release
> 11
> -bottom
> 'Copyright © 2023. All rights reserved.'
> -charset
> 'UTF-8'
> -d
> '/Users/henning/scratch/mjavadoc769/target/apidocs'
> -docencoding
> 'UTF-8'
> -Xdoclint:none
> -doctitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> -linkoffline
> 'https://docs.oracle.com/en/java/javase/11/docs/api'
> '/Users/henning/scratch/mjavadoc769/target/javadoc-bundle-options'
> -nohelp
> -use
> -version
> -windowtitle
> 'mjavadoc769 1.0-SNAPSHOT API'
> {code}
> The javadoc plugin decides that the "javax.inject-1.jar" is added to the
> classpath even though it is an optional dependency of the main module.
> Contrary to this, the jakarta.inject-api-2.0.1.MR.jar is added to the module
> path.
> The reason for this may be that the jakarta module contains a module-info
> (hidden in META-INF/versions/9/) while the javax.inject jar does not.
> However, the checker-qual
> (org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar) dependency
> is put on the module path even though it does not contain a module-info file.
> However, it contains an {{Automatic-Module-Name}} entry in META-INF/MANIFEST.
> It seems that the javadoc plugin treats automatic dependencies with entry in
> the manifest different from automatic dependencies determined by filename.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-javadoc-plugin] hgschmie opened a new pull request, #227: [MJAVADOC-769] fix for transitive filename based modules
hgschmie opened a new pull request, #227: URL: https://github.com/apache/maven-javadoc-plugin/pull/227 When a project depends on an artifact with a manifest entry for Automatic-Module-Name which in turn depends on an artifact that uses the filename to determine the module name, it will move the former onto the module path and patch the latter into the main artifact. However, now the direct dependency on the module path can no longer access the classes that have been patched only into the main module and javadoc generation fails. As the JDK only differentiates between modules with a module descriptor and "everything else" (modules with an automatic module entry in the manifest and modules with file name based names), the javadoc plugin should do the same. This patch changes the treatment of dependencies with an Automatic-Module-Name to match dependencies that use a filename based module name. The plugin now patches all of those dependencies into the main module and the build succeeds. Includes an integration test. 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/MJAVADOC) 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 `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-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 verify -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. 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 licensed 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
[jira] [Commented] (MJAVADOC-769) javadoc plugin can not deal with transitive filename based modules
[
https://issues.apache.org/jira/browse/MJAVADOC-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757095#comment-17757095
]
ASF GitHub Bot commented on MJAVADOC-769:
-
hgschmie opened a new pull request, #227:
URL: https://github.com/apache/maven-javadoc-plugin/pull/227
When a project depends on an artifact with a manifest entry for
Automatic-Module-Name which in turn depends on an artifact that uses the
filename to determine the module name, it will move the former onto the
module path and patch the latter into the main artifact. However, now
the direct dependency on the module path can no longer access the
classes that have been patched only into the main module and javadoc
generation fails.
As the JDK only differentiates between modules with a module descriptor
and "everything else" (modules with an automatic module entry in the
manifest and modules with file name based names), the javadoc plugin
should do the same.
This patch changes the treatment of dependencies with an
Automatic-Module-Name to match dependencies that use a filename based
module name. The plugin now patches all of those dependencies into the
main module and the build succeeds.
Includes an integration test.
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/MJAVADOC) 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 `[MJAVADOC-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MJAVADOC-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 verify -Prun-its` to make sure basic checks pass. A
more thorough check will
be performed on your pull request automatically.
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 licensed under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
> javadoc plugin can not deal with transitive filename based modules
> --
>
> Key: MJAVADOC-769
> URL: https://issues.apache.org/jira/browse/MJAVADOC-769
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.5.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> clone this repository: https://github.com/hgschmie/mjavadoc769
> This builds an artifact, a tests artifact and a javadoc jar.
> When building this for Java 9+ compatibility (javadoc generate a list of
> modules) and using modules with Automatic-Module-Name enabled, the javadoc
> plugin can not access the optional dependencies:
> {code}
> ERROR] Exit code: 1
> [ERROR]
> /Users/henning/scratch/mjavadoc769/src/main/java/mavenbugs/mjavadoc769/InternalImportBindingBuilder.java:88:
> error: cannot access Provider
> [ERROR] static final class InternalBindingProvider implements
> Provider {
> [ERROR] ^
> [ERROR] class file for javax.inject.Provider not found
> [ERROR] 1 error
> [ERROR] Command line was:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/javadoc
> -J-Xmx1024m @options @packages
> {code}
> Note that all other plugins (compiler, surefire) work fine. Just the javadoc
> plugin does not.
> {code}
> --add-modules
> ALL-MODULE-PATH
> --module-path
> '/Users/henning/.m2/repository/org/checkerframework/checker-qual/3.12.0/checker-qual-3.12.0.jar:/Users/henning/.m2/repository/jakarta/inject/jakarta.inject-api/2.0.1.MR/jakarta.inject-api-2.0.1.MR.jar:/Users/henning/.m2/repository/com/google/inject/guice/5.1.0/guice-5.1.0.jar:/Users/henning/.m2/repository/com/google/errorprone/error_prone_annotations/2.11.0/error_prone_annotations-2.11.0.jar:/Users/henning/.m2/repository/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar:/Users/henning/scratch/mjavadoc769/target/mjavadoc769-1.0-SNAPSHOT.jar'
> --patch-module
> mavenbugs.mjavadoc769='/Users/henning/scratch/mjavadoc769/src/main/java:/Users/henning/scr
[GitHub] [maven-site] dependabot[bot] opened a new pull request, #444: Bump org.apache.ant:ant from 1.10.13 to 1.10.14
dependabot[bot] opened a new pull request, #444: URL: https://github.com/apache/maven-site/pull/444 Bumps org.apache.ant:ant from 1.10.13 to 1.10.14. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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
[GitHub] [maven] gnodet commented on pull request #1210: [MNG-7851] Improve error message when modelVersion is 4.0
gnodet commented on PR #1210: URL: https://github.com/apache/maven/pull/1210#issuecomment-1687527207 > If we're going litteral, shouldn't we simply check that the version in the model is one of the supported version. The `validateModelVersion` could be simplified to just check the version is supported or thrown an exception without having to check for newer / older versions. @candrews could you simplify the code for the [`validateModelVersion`](https://github.com/apache/maven/blob/78da8ff662d9c9e0ba87aa2138114d8fd393855c/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L1383-L1460) method so that it simply checks if the version is in the provided set instead (third branch of the tests) instead of comparing with all other versions ? -- 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] (MNG-7851) Error message when modelVersion is 4.0 is confusing
[
https://issues.apache.org/jira/browse/MNG-7851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757215#comment-17757215
]
ASF GitHub Bot commented on MNG-7851:
-
gnodet commented on PR #1210:
URL: https://github.com/apache/maven/pull/1210#issuecomment-1687527207
> If we're going litteral, shouldn't we simply check that the version in the
model is one of the supported version. The `validateModelVersion` could be
simplified to just check the version is supported or thrown an exception
without having to check for newer / older versions.
@candrews could you simplify the code for the
[`validateModelVersion`](https://github.com/apache/maven/blob/78da8ff662d9c9e0ba87aa2138114d8fd393855c/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L1383-L1460)
method so that it simply checks if the version is in the provided set instead
(third branch of the tests) instead of comparing with all other versions ?
> Error message when modelVersion is 4.0 is confusing
> ---
>
> Key: MNG-7851
> URL: https://issues.apache.org/jira/browse/MNG-7851
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.9.3
>Reporter: Craig
>Priority: Minor
>
> When a pom with modelVersion 4.0 is referenced, such as this one:
> {code:xml}
>
> 4.0
> foo
> bar
> 0.1
>
> {code}
> The error message is:
> {{'modelVersion' of '4.0' is newer than the versions supported by this
> version of Maven: [4.0.0]. Building this project requires a newer version of
> Maven.}}
>
> That's misleading.
> A better error message would be:
> {{'modelVersion' must be one of [4.0.0] but is '4.0'.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1197: [MNG-7836] Support alternative syntaxes for POMs
gnodet commented on code in PR #1197:
URL: https://github.com/apache/maven/pull/1197#discussion_r1301069222
##
maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java:
##
@@ -165,31 +178,50 @@ private ConsumerPomArtifact(MavenProject mavenProject,
Path target, RepositorySy
target,
transformer(session));
}
+}
-private static BiConsumer
transformer(RepositorySystemSession session) {
-TransformerContext context = (TransformerContext)
session.getData().get(TransformerContext.KEY);
-return (src, dest) -> {
-try (InputStream inputStream = transform(src, context)) {
-Files.createDirectories(dest.getParent());
-Files.copy(inputStream, dest,
StandardCopyOption.REPLACE_EXISTING);
-} catch (XMLStreamException | IOException e) {
-throw new RuntimeException(e);
-}
-};
-}
+BiConsumer transformer(RepositorySystemSession session) {
+TransformerContext context = (TransformerContext)
session.getData().get(TransformerContext.KEY);
+return (src, dest) -> {
+try {
+Files.createDirectories(dest.getParent());
+transform(src, dest, context);
+} catch (XMLStreamException | IOException e) {
+throw new RuntimeException(e);
Review Comment:
This discussion does not belong to this PR, as this is a design decision in
the v4 api and can't be changed in this smaller PR.
--
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] (MNG-7836) Support alternative syntaxes for POMs
[
https://issues.apache.org/jira/browse/MNG-7836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757217#comment-17757217
]
ASF GitHub Bot commented on MNG-7836:
-
gnodet commented on code in PR #1197:
URL: https://github.com/apache/maven/pull/1197#discussion_r1301069222
##
maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java:
##
@@ -165,31 +178,50 @@ private ConsumerPomArtifact(MavenProject mavenProject,
Path target, RepositorySy
target,
transformer(session));
}
+}
-private static BiConsumer
transformer(RepositorySystemSession session) {
-TransformerContext context = (TransformerContext)
session.getData().get(TransformerContext.KEY);
-return (src, dest) -> {
-try (InputStream inputStream = transform(src, context)) {
-Files.createDirectories(dest.getParent());
-Files.copy(inputStream, dest,
StandardCopyOption.REPLACE_EXISTING);
-} catch (XMLStreamException | IOException e) {
-throw new RuntimeException(e);
-}
-};
-}
+BiConsumer transformer(RepositorySystemSession session) {
+TransformerContext context = (TransformerContext)
session.getData().get(TransformerContext.KEY);
+return (src, dest) -> {
+try {
+Files.createDirectories(dest.getParent());
+transform(src, dest, context);
+} catch (XMLStreamException | IOException e) {
+throw new RuntimeException(e);
Review Comment:
This discussion does not belong to this PR, as this is a design decision in
the v4 api and can't be changed in this smaller PR.
> Support alternative syntaxes for POMs
> -
>
> Key: MNG-7836
> URL: https://issues.apache.org/jira/browse/MNG-7836
> Project: Maven
> Issue Type: New Feature
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
