[jira] [Closed] (MSHADE-476) Upgrade commons-compress to 1.26.2
[ https://issues.apache.org/jira/browse/MSHADE-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHADE-476. --- Resolution: Fixed fixed with https://github.com/apache/maven-shade-plugin/commit/199ffaecd26a912527173ed4edae366e48a00998 > Upgrade commons-compress to 1.26.2 > -- > > Key: MSHADE-476 > URL: https://issues.apache.org/jira/browse/MSHADE-476 > Project: Maven Shade Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHADE-475) Upgrade commons-io to 2.16.1
[ https://issues.apache.org/jira/browse/MSHADE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHADE-475. --- Resolution: Fixed fixed with https://github.com/apache/maven-shade-plugin/commit/199ffaecd26a912527173ed4edae366e48a00998 > Upgrade commons-io to 2.16.1 > > > Key: MSHADE-475 > URL: https://issues.apache.org/jira/browse/MSHADE-475 > Project: Maven Shade Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHADE-477) (test) Upgrade test dependencies
[ https://issues.apache.org/jira/browse/MSHADE-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHADE-477. --- Resolution: Fixed fixed with https://github.com/apache/maven-shade-plugin/commit/199ffaecd26a912527173ed4edae366e48a00998 > (test) Upgrade test dependencies > > > Key: MSHADE-477 > URL: https://issues.apache.org/jira/browse/MSHADE-477 > Project: Maven Shade Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.6.0 > > > Such as: > * xmlunit 2.10.0 > * mockito 3.12.4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHADE-473) Drop plugin cruft
[ https://issues.apache.org/jira/browse/MSHADE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHADE-473. --- Resolution: Fixed fixed with https://github.com/apache/maven-shade-plugin/commit/199ffaecd26a912527173ed4edae366e48a00998 > Drop plugin cruft > - > > Key: MSHADE-473 > URL: https://issues.apache.org/jira/browse/MSHADE-473 > Project: Maven Shade Plugin > Issue Type: Task >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.6.0 > > > Plugin drags a lot of legacy and superfluous dependencies, get rid of them. > Such as maven-dependency-tree (that is about to be deprecated) and few lines > in one class uses commons-collections4. These are all not really necessary > and are just burden. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHADE-474) Align dependencies with Maven 3 (as this is Maven3 plugin)
[ https://issues.apache.org/jira/browse/MSHADE-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHADE-474. --- Resolution: Fixed fixed with https://github.com/apache/maven-shade-plugin/commit/199ffaecd26a912527173ed4edae366e48a00998 > Align dependencies with Maven 3 (as this is Maven3 plugin) > -- > > Key: MSHADE-474 > URL: https://issues.apache.org/jira/browse/MSHADE-474 > Project: Maven Shade Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.6.0 > > > Such as: > * slf4j 1.7.36 > * plexus-util 3.5.1 > * sisu 0.9.0.M2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1403) Configure log file as as File (not only file name relative to base directory)
[ https://issues.apache.org/jira/browse/MSHARED-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHARED-1403. - Resolution: Fixed > Configure log file as as File (not only file name relative to base directory) > - > > Key: MSHARED-1403 > URL: https://issues.apache.org/jira/browse/MSHARED-1403 > Project: Maven Shared Components > Issue Type: Task > Components: maven-verifier >Affects Versions: maven-verifier-2.0.0-M1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: maven-verifier-2.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1403) Configure log file as as File (not only file name relative to base directory)
[ https://issues.apache.org/jira/browse/MSHARED-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSHARED-1403: -- Fix Version/s: maven-verifier-2.0.0 (was: maven-verifier-next) > Configure log file as as File (not only file name relative to base directory) > - > > Key: MSHARED-1403 > URL: https://issues.apache.org/jira/browse/MSHARED-1403 > Project: Maven Shared Components > Issue Type: Task > Components: maven-verifier >Affects Versions: maven-verifier-2.0.0-M1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: maven-verifier-2.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1403) Configure log file as as File (not only file name relative to base directory)
[ https://issues.apache.org/jira/browse/MSHARED-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MSHARED-1403: -- Summary: Configure log file as as File (not only file name relative to base directory) (was: Configure log file as as file (not only file relative to base directory)) > Configure log file as as File (not only file name relative to base directory) > - > > Key: MSHARED-1403 > URL: https://issues.apache.org/jira/browse/MSHARED-1403 > Project: Maven Shared Components > Issue Type: Task > Components: maven-verifier >Affects Versions: maven-verifier-2.0.0-M1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: maven-verifier-next > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1403) Configure log file as as file (not only file relative to base directory)
Olivier Lamy created MSHARED-1403: - Summary: Configure log file as as file (not only file relative to base directory) Key: MSHARED-1403 URL: https://issues.apache.org/jira/browse/MSHARED-1403 Project: Maven Shared Components Issue Type: Task Components: maven-verifier Affects Versions: maven-verifier-2.0.0-M1 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: maven-verifier-next -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MSHARED-1357) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MSHARED-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MSHARED-1357: - Assignee: Olivier Lamy > Upgrade Parent to 41 > > > Key: MSHARED-1357 > URL: https://issues.apache.org/jira/browse/MSHARED-1357 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-verifier >Reporter: Slawomir Jaranowski >Assignee: Olivier Lamy >Priority: Major > Labels: up-for-grabs > Fix For: maven-verifier-next > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1357) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MSHARED-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MSHARED-1357. - Fix Version/s: (was: maven-verifier-next) Resolution: Duplicate > Upgrade Parent to 41 > > > Key: MSHARED-1357 > URL: https://issues.apache.org/jira/browse/MSHARED-1357 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-verifier >Reporter: Slawomir Jaranowski >Assignee: Olivier Lamy >Priority: Major > Labels: up-for-grabs > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MASSEMBLY-1030) Manifest entries from archive configuration are not added in final MANIFEST
[
https://issues.apache.org/jira/browse/MASSEMBLY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MASSEMBLY-1030.
---
Resolution: Fixed
> Manifest entries from archive configuration are not added in final MANIFEST
> ---
>
> Key: MASSEMBLY-1030
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1030
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 3.7.1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.2
>
>
> given the follow configuration
> {code:java}
>
>
> src/main/assembly/web-bundle.xml
>
>
>
> ${project.build.outputDirectory}/META-INF/MANIFEST.MF
>
> ee10
>
>
> merge
> {code}
> he entries from manifestEntries are not added to MANIFEST file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-96) Remove usage of maven-compat
[ https://issues.apache.org/jira/browse/MBUILDCACHE-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MBUILDCACHE-96: Fix Version/s: 1.3.0 > Remove usage of maven-compat > > > Key: MBUILDCACHE-96 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-96 > Project: Maven Build Cache Extension > Issue Type: Task >Affects Versions: 1.2.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 1.3.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-96) Remove usage of maven-compat
Olivier Lamy created MBUILDCACHE-96: --- Summary: Remove usage of maven-compat Key: MBUILDCACHE-96 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-96 Project: Maven Build Cache Extension Issue Type: Task Affects Versions: 1.2.0 Reporter: Olivier Lamy Assignee: Olivier Lamy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-1030) Manifest entries from archive configuration are not added in final MANIFEST
[
https://issues.apache.org/jira/browse/MASSEMBLY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MASSEMBLY-1030:
Summary: Manifest entries from archive configuration are not added in final
MANIFEST (was: Manifest entries from archive configuration are not added )
> Manifest entries from archive configuration are not added in final MANIFEST
> ---
>
> Key: MASSEMBLY-1030
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1030
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 3.7.1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.2
>
>
> given the follow configuration
> {code:java}
>
>
> src/main/assembly/web-bundle.xml
>
>
>
> ${project.build.outputDirectory}/META-INF/MANIFEST.MF
>
> ee10
>
>
> merge
> {code}
> he entries from manifestEntries are not added to MANIFEST file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-1030) Manifest entries from archive configuration are not added
[
https://issues.apache.org/jira/browse/MASSEMBLY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MASSEMBLY-1030:
Description:
given the follow configuration
{code:java}
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
{code}
he entries from manifestEntries are not added to MANIFEST file
was:
given the follow configuration
{{
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
}}
the entries from manifestEntries are not added to MANIFEST file
> Manifest entries from archive configuration are not added
> --
>
> Key: MASSEMBLY-1030
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1030
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 3.7.1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.2
>
>
> given the follow configuration
> {code:java}
>
>
> src/main/assembly/web-bundle.xml
>
>
>
> ${project.build.outputDirectory}/META-INF/MANIFEST.MF
>
> ee10
>
>
> merge
> {code}
> he entries from manifestEntries are not added to MANIFEST file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MASSEMBLY-1030) Manifest entries from archive configuration are not added
[
https://issues.apache.org/jira/browse/MASSEMBLY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MASSEMBLY-1030:
Description:
given the follow configuration
{{
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
}}
the entries from manifestEntries are not added to MANIFEST file
was:
given the follow configuration
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
the entries from manifestEntries are not added to MANIFEST file
> Manifest entries from archive configuration are not added
> --
>
> Key: MASSEMBLY-1030
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1030
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 3.7.1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.2
>
>
> given the follow configuration
> {{
>
> src/main/assembly/web-bundle.xml
>
>
>
> ${project.build.outputDirectory}/META-INF/MANIFEST.MF
>
> ee10
>
>
> merge
> }}
> the entries from manifestEntries are not added to MANIFEST file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MASSEMBLY-1030) Manifest entries from archive configuration are not added
Olivier Lamy created MASSEMBLY-1030:
---
Summary: Manifest entries from archive configuration are not added
Key: MASSEMBLY-1030
URL: https://issues.apache.org/jira/browse/MASSEMBLY-1030
Project: Maven Assembly Plugin
Issue Type: Bug
Components: manifest
Affects Versions: 3.7.1
Reporter: Olivier Lamy
Assignee: Olivier Lamy
Fix For: 3.7.2
given the follow configuration
src/main/assembly/web-bundle.xml
${project.build.outputDirectory}/META-INF/MANIFEST.MF
ee10
merge
the entries from manifestEntries are not added to MANIFEST file
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-88) Tests in failure when ran on jdk21
[
https://issues.apache.org/jira/browse/MBUILDCACHE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-88.
---
Resolution: Fixed
> Tests in failure when ran on jdk21
> --
>
> Key: MBUILDCACHE-88
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Kevin Buntrock
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> The project tests cannot be run on jdk21. Result is :
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
> but was:
> [ERROR]
> CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalEnabledByUserProperty:436->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalEnabledByUserProperty$51:439
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled:455->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled$54:457
> expected: but was:
> [INFO]
> [ERROR] Tests run: 71, Failures: 10, Errors: 0, Skipped: 4
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> {code}
> In class "CacheConfigImplTest", a method "deepMockConfigFile" mocks the
> result of the call to java.nio.file.Files.exists (via
> "FileSystemProvider.checkAccess").
> In jdk21 version, "Files.exists" does not rely on the same underlying
> "FileSystemProvider" method, therefore breaking the mocking purpose.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8116) Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attriute
[
https://issues.apache.org/jira/browse/MNG-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MNG-8116:
-
Assignee: Olivier Lamy
> Plugin configuration can randomly fail in case of method overloading as it
> doesn't take into account implementation attriute
>
>
> Key: MNG-8116
> URL: https://issues.apache.org/jira/browse/MNG-8116
> Project: Maven
> Issue Type: Task
> Components: Plugin Requests
>Affects Versions: 3.9.6
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.9.7
>
>
> Originally discovered via a Jetty bug report see
> https://github.com/jetty/jetty.project/issues/11732
> The bean to configured have the following overloading method naming:
> * public void setExtraClasspath(String extraClasspath)
> * public void setExtraClasspath(List extraClasspath)
> The plugin configuration:
>
> ${basedir}/config
>
> even forcing the implementation attribute doesn't help
>
>implementation="java.lang.String">${basedir}/config
>
> The fix is implemented via the PR
> https://github.com/eclipse/sisu.plexus/pull/52
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8116) Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attriute
[
https://issues.apache.org/jira/browse/MNG-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MNG-8116:
--
Description:
Originally discovered via a Jetty bug report see
https://github.com/jetty/jetty.project/issues/11732
The bean to configured have the following overloading method naming:
* public void setExtraClasspath(String extraClasspath)
* public void setExtraClasspath(List extraClasspath)
The plugin configuration:
${basedir}/config
even forcing the implementation attribute doesn't help
${basedir}/config
The fix is implemented via the PR https://github.com/eclipse/sisu.plexus/pull/52
was:
Originally discovered via a Jetty bug report see
https://github.com/jetty/jetty.project/issues/11732
The bean to configured have the following overloading method naming:
* public void setExtraClasspath(String extraClasspath)
* public void setExtraClasspath(List extraClasspath)
The plugin configuration:
> Plugin configuration can randomly fail in case of method overloading as it
> doesn't take into account implementation attriute
>
>
> Key: MNG-8116
> URL: https://issues.apache.org/jira/browse/MNG-8116
> Project: Maven
> Issue Type: Task
> Components: Plugin Requests
>Affects Versions: 3.9.6
>Reporter: Olivier Lamy
>Priority: Major
> Fix For: 3.9.7
>
>
> Originally discovered via a Jetty bug report see
> https://github.com/jetty/jetty.project/issues/11732
> The bean to configured have the following overloading method naming:
> * public void setExtraClasspath(String extraClasspath)
> * public void setExtraClasspath(List extraClasspath)
> The plugin configuration:
>
> ${basedir}/config
>
> even forcing the implementation attribute doesn't help
>
>implementation="java.lang.String">${basedir}/config
>
> The fix is implemented via the PR
> https://github.com/eclipse/sisu.plexus/pull/52
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8116) Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attriute
[ https://issues.apache.org/jira/browse/MNG-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MNG-8116: -- Description: Originally discovered via a Jetty bug report see https://github.com/jetty/jetty.project/issues/11732 The bean to configured have the following overloading method naming: * public void setExtraClasspath(String extraClasspath) * public void setExtraClasspath(List extraClasspath) The plugin configuration: > Plugin configuration can randomly fail in case of method overloading as it > doesn't take into account implementation attriute > > > Key: MNG-8116 > URL: https://issues.apache.org/jira/browse/MNG-8116 > Project: Maven > Issue Type: Task > Components: Plugin Requests >Affects Versions: 3.9.6 >Reporter: Olivier Lamy >Priority: Major > Fix For: 3.9.7 > > > Originally discovered via a Jetty bug report see > https://github.com/jetty/jetty.project/issues/11732 > The bean to configured have the following overloading method naming: > * public void setExtraClasspath(String extraClasspath) > * public void setExtraClasspath(List extraClasspath) > The plugin configuration: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8116) Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attriute
Olivier Lamy created MNG-8116: - Summary: Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attriute Key: MNG-8116 URL: https://issues.apache.org/jira/browse/MNG-8116 Project: Maven Issue Type: Task Components: Plugin Requests Affects Versions: 3.9.6 Reporter: Olivier Lamy Fix For: 3.9.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MBUILDCACHE-86. --- Assignee: Olivier Lamy Resolution: Fixed > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Assignee: Olivier Lamy >Priority: Major > Labels: pull-request-available > Fix For: 1.2.0 > > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-90) Configuration option to make mandatory the use of the clean phase in order to cache the build result
[ https://issues.apache.org/jira/browse/MBUILDCACHE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MBUILDCACHE-90. --- Resolution: Fixed > Configuration option to make mandatory the use of the clean phase in order to > cache the build result > > > Key: MBUILDCACHE-90 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-90 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Assignee: Olivier Lamy >Priority: Minor > Labels: pull-request-available > Fix For: 1.2.0 > > > Add a configuration option to make mandatory the use of the clean phase in > order to cache the build result. > The goal is to offer the possibility of denying as much as possible the > possibility to cache a faulty build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-90) Configuration option to make mandatory the use of the clean phase in order to cache the build result
[ https://issues.apache.org/jira/browse/MBUILDCACHE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MBUILDCACHE-90: Fix Version/s: 1.2.0 > Configuration option to make mandatory the use of the clean phase in order to > cache the build result > > > Key: MBUILDCACHE-90 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-90 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Assignee: Olivier Lamy >Priority: Minor > Labels: pull-request-available > Fix For: 1.2.0 > > > Add a configuration option to make mandatory the use of the clean phase in > order to cache the build result. > The goal is to offer the possibility of denying as much as possible the > possibility to cache a faulty build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-90) Configuration option to make mandatory the use of the clean phase in order to cache the build result
[ https://issues.apache.org/jira/browse/MBUILDCACHE-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MBUILDCACHE-90: --- Assignee: Olivier Lamy > Configuration option to make mandatory the use of the clean phase in order to > cache the build result > > > Key: MBUILDCACHE-90 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-90 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Assignee: Olivier Lamy >Priority: Minor > Labels: pull-request-available > > Add a configuration option to make mandatory the use of the clean phase in > order to cache the build result. > The goal is to offer the possibility of denying as much as possible the > possibility to cache a faulty build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-93) Command line configuration to disable saving in cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MBUILDCACHE-93. --- Resolution: Fixed PR merged. Thanks for your contribution! > Command line configuration to disable saving in cache > - > > Key: MBUILDCACHE-93 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Assignee: Olivier Lamy >Priority: Minor > Labels: pull-request-available > > Command line configuration to disable saving in cache. > We have already a configuration to : > - Disable totally any cache interaction > - Disable restoring from the cache > - Disable saving on the remote cache > But there is no configuration to disable "classic" saving to the cache. > Use case can be : > Having limited space on machine and therefore a limited number of saved build > allowed. > -> Restricting cache save to the "master" branch / configuring PR branch > build to benefits from the cache, but disallowing any save from them > It's personally a functionality I use since November and the cache hit rate > on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-93) Command line configuration to disable saving in cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MBUILDCACHE-93: --- Assignee: Olivier Lamy > Command line configuration to disable saving in cache > - > > Key: MBUILDCACHE-93 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-93 > Project: Maven Build Cache Extension > Issue Type: New Feature >Reporter: Kevin Buntrock >Assignee: Olivier Lamy >Priority: Minor > Labels: pull-request-available > > Command line configuration to disable saving in cache. > We have already a configuration to : > - Disable totally any cache interaction > - Disable restoring from the cache > - Disable saving on the remote cache > But there is no configuration to disable "classic" saving to the cache. > Use case can be : > Having limited space on machine and therefore a limited number of saved build > allowed. > -> Restricting cache save to the "master" branch / configuring PR branch > build to benefits from the cache, but disallowing any save from them > It's personally a functionality I use since November and the cache hit rate > on my project with this technic is pretty nice. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-88) Tests in failure when ran on jdk21
[
https://issues.apache.org/jira/browse/MBUILDCACHE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MBUILDCACHE-88:
---
Assignee: Olivier Lamy
> Tests in failure when ran on jdk21
> --
>
> Key: MBUILDCACHE-88
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Kevin Buntrock
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
>
> The project tests cannot be run on jdk21. Result is :
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
> but was:
> [ERROR]
> CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalEnabledByUserProperty:436->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalEnabledByUserProperty$51:439
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled:455->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled$54:457
> expected: but was:
> [INFO]
> [ERROR] Tests run: 71, Failures: 10, Errors: 0, Skipped: 4
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> {code}
> In class "CacheConfigImplTest", a method "deepMockConfigFile" mocks the
> result of the call to java.nio.file.Files.exists (via
> "FileSystemProvider.checkAccess").
> In jdk21 version, "Files.exists" does not rely on the same underlying
> "FileSystemProvider" method, therefore breaking the mocking purpose.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-88) Tests in failure when ran on jdk21
[
https://issues.apache.org/jira/browse/MBUILDCACHE-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-88:
Fix Version/s: 1.2.0
> Tests in failure when ran on jdk21
> --
>
> Key: MBUILDCACHE-88
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-88
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Kevin Buntrock
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> The project tests cannot be run on jdk21. Result is :
> {code:java}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] CacheConfigImplTest.testInitializationDisabledInXML:234 expected:
> but was:
> [ERROR]
> CacheConfigImplTest.testRemoteDisableByUserPropertyOverride:330->assertDefaults:137->assertDefaults:201->lambda$testRemoteDisableByUserPropertyOverride$39:330
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableByUserPropertyOverrideWithURL:313->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableByUserPropertyOverrideWithURL$38:315
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteEnableInXMLWithURL:288->assertDefaults:137->assertDefaults:201->lambda$testRemoteEnableInXMLWithURL$36:290
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride:420->assertDefaults:137->assertDefaults:201->lambda$testRemoteSaveIgnoredWhenRemoteDisabledByUserPropertyOverride$48:420
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveDisabledByUserProperty:381->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveDisabledByUserProperty$47:383
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledByUserProperty:362->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledByUserProperty$45:365
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveEnabledInXML:344->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveEnabledInXML$42:347
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalEnabledByUserProperty:436->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalEnabledByUserProperty$51:439
> expected: but was:
> [ERROR]
> CacheConfigImplTest.testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled:455->assertDefaults:137->assertDefaults:201->lambda$testRemoveSaveFinalIgnoredWhenRemoteSaveDisabled$54:457
> expected: but was:
> [INFO]
> [ERROR] Tests run: 71, Failures: 10, Errors: 0, Skipped: 4
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
> {code}
> In class "CacheConfigImplTest", a method "deepMockConfigFile" mocks the
> result of the call to java.nio.file.Files.exists (via
> "FileSystemProvider.checkAccess").
> In jdk21 version, "Files.exists" does not rely on the same underlying
> "FileSystemProvider" method, therefore breaking the mocking purpose.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-50) Unsupported phase: null with dependency:analyze in multimodule project
[
https://issues.apache.org/jira/browse/MBUILDCACHE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-50:
Fix Version/s: 1.0.0
> Unsupported phase: null with dependency:analyze in multimodule project
> --
>
> Key: MBUILDCACHE-50
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-50
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 x64
> Maven 3.9.1
> Java 20 (Eclipse Adoptium)
>Reporter: Thorsten Heit
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: pomtest.tar.bz2
>
>
> Executing {{"mvn dependency:analyze"}} results in an error message
> "Unsupported phase: null" when the first submodule of a multimodule project
> is being analyzed.
> I've attached a very simple project that can be used to demonstrate the
> behaviour: As long as the {{.mvn}} folder exists and the build cache
> extension is active, executing {{"mvn dependency:analyze"}} or {{"mvn
> dependency:3.5.0:analyze"}} don't work. Rename the folder => works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-50) Unsupported phase: null with dependency:analyze in multimodule project
[
https://issues.apache.org/jira/browse/MBUILDCACHE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-50.
---
Resolution: Fixed
> Unsupported phase: null with dependency:analyze in multimodule project
> --
>
> Key: MBUILDCACHE-50
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-50
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 x64
> Maven 3.9.1
> Java 20 (Eclipse Adoptium)
>Reporter: Thorsten Heit
>Priority: Major
> Fix For: 1.0.0
>
> Attachments: pomtest.tar.bz2
>
>
> Executing {{"mvn dependency:analyze"}} results in an error message
> "Unsupported phase: null" when the first submodule of a multimodule project
> is being analyzed.
> I've attached a very simple project that can be used to demonstrate the
> behaviour: As long as the {{.mvn}} folder exists and the build cache
> extension is active, executing {{"mvn dependency:analyze"}} or {{"mvn
> dependency:3.5.0:analyze"}} don't work. Rename the folder => works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-50) Unsupported phase: null with dependency:analyze in multimodule project
[
https://issues.apache.org/jira/browse/MBUILDCACHE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832111#comment-17832111
]
Olivier Lamy commented on MBUILDCACHE-50:
-
This have been merged long time and so already available.
> Unsupported phase: null with dependency:analyze in multimodule project
> --
>
> Key: MBUILDCACHE-50
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-50
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 x64
> Maven 3.9.1
> Java 20 (Eclipse Adoptium)
>Reporter: Thorsten Heit
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: pomtest.tar.bz2
>
>
> Executing {{"mvn dependency:analyze"}} results in an error message
> "Unsupported phase: null" when the first submodule of a multimodule project
> is being analyzed.
> I've attached a very simple project that can be used to demonstrate the
> behaviour: As long as the {{.mvn}} folder exists and the build cache
> extension is active, executing {{"mvn dependency:analyze"}} or {{"mvn
> dependency:3.5.0:analyze"}} don't work. Rename the folder => works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-50) Unsupported phase: null with dependency:analyze in multimodule project
[
https://issues.apache.org/jira/browse/MBUILDCACHE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-50:
Fix Version/s: (was: 1.2.0)
> Unsupported phase: null with dependency:analyze in multimodule project
> --
>
> Key: MBUILDCACHE-50
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-50
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 x64
> Maven 3.9.1
> Java 20 (Eclipse Adoptium)
>Reporter: Thorsten Heit
>Priority: Major
> Attachments: pomtest.tar.bz2
>
>
> Executing {{"mvn dependency:analyze"}} results in an error message
> "Unsupported phase: null" when the first submodule of a multimodule project
> is being analyzed.
> I've attached a very simple project that can be used to demonstrate the
> behaviour: As long as the {{.mvn}} folder exists and the build cache
> extension is active, executing {{"mvn dependency:analyze"}} or {{"mvn
> dependency:3.5.0:analyze"}} don't work. Rename the folder => works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-71) buildinfo.xml should be stored after storing the project's artifacts
[
https://issues.apache.org/jira/browse/MBUILDCACHE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-71.
---
Resolution: Fixed
Thanks for the contribution!
> buildinfo.xml should be stored after storing the project's artifacts
>
>
> Key: MBUILDCACHE-71
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-71
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Affects Versions: 1.0.1
>Reporter: Amir Hadadi
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> In certain failure cases it's possible that only part of a module artifacts
> get stored in the local and remote storage. In that case if buildinfo.xml got
> stored, the extension will later incorrectly attempt to restore the partially
> cached build.
> Because buildinfo.xml is used as an indication that the cached artifacts
> exist, I propose to reorder the logic in
> {code:java}
> CacheControllerImpl.save(){code}
> so that
> {code:java}
> localCache.saveBuildInfo(cacheResult, build);{code}
> will happen after the project's artifacts are stored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-71) buildinfo.xml should be stored after storing the project's artifacts
[
https://issues.apache.org/jira/browse/MBUILDCACHE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MBUILDCACHE-71:
---
Assignee: Olivier Lamy
> buildinfo.xml should be stored after storing the project's artifacts
>
>
> Key: MBUILDCACHE-71
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-71
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Affects Versions: 1.0.1
>Reporter: Amir Hadadi
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> In certain failure cases it's possible that only part of a module artifacts
> get stored in the local and remote storage. In that case if buildinfo.xml got
> stored, the extension will later incorrectly attempt to restore the partially
> cached build.
> Because buildinfo.xml is used as an indication that the cached artifacts
> exist, I propose to reorder the logic in
> {code:java}
> CacheControllerImpl.save(){code}
> so that
> {code:java}
> localCache.saveBuildInfo(cacheResult, build);{code}
> will happen after the project's artifacts are stored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-71) buildinfo.xml should be stored after storing the project's artifacts
[
https://issues.apache.org/jira/browse/MBUILDCACHE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-71:
Fix Version/s: 1.2.0
> buildinfo.xml should be stored after storing the project's artifacts
>
>
> Key: MBUILDCACHE-71
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-71
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Affects Versions: 1.0.1
>Reporter: Amir Hadadi
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> In certain failure cases it's possible that only part of a module artifacts
> get stored in the local and remote storage. In that case if buildinfo.xml got
> stored, the extension will later incorrectly attempt to restore the partially
> cached build.
> Because buildinfo.xml is used as an indication that the cached artifacts
> exist, I propose to reorder the logic in
> {code:java}
> CacheControllerImpl.save(){code}
> so that
> {code:java}
> localCache.saveBuildInfo(cacheResult, build);{code}
> will happen after the project's artifacts are stored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSOURCES-141) Check duplication of attached jar should be configurable to not fail when using the build cache
[
https://issues.apache.org/jira/browse/MSOURCES-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MSOURCES-141:
--
Fix Version/s: backlog
(was: 3.3.1)
> Check duplication of attached jar should be configurable to not fail when
> using the build cache
> ---
>
> Key: MSOURCES-141
> URL: https://issues.apache.org/jira/browse/MSOURCES-141
> Project: Maven Source Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: backlog
>
> Attachments: issue-msources-141.zip
>
>
> because MSOURCES-121 using source jar mojo and build cache generate an error
> as the cache restore a project with attached artifacts and so the source mojo
> fail because of this.
> {code}
> Caused by: org.apache.maven.plugin.MojoExecutionException: Presumably you
> have configured maven-source-plugn to execute twice times in your build. You
> have to configure a classifier for at least on of them.
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources
> (AbstractSourceJarMojo.java:309)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources
> (AbstractSourceJarMojo.java:257)
> at org.apache.maven.plugins.source.AbstractSourceJarMojo.execute
> (AbstractSourceJarMojo.java:225)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:224)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:131)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINVOKER-355) Update Groovy 4.0.18 to 4.0.20 to support jdk22
[ https://issues.apache.org/jira/browse/MINVOKER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MINVOKER-355: -- Summary: Update Groovy 4.0.18 to 4.0.20 to support jdk22 (was: Update 4.0.18 to 4.0.20 to support jdk22) > Update Groovy 4.0.18 to 4.0.20 to support jdk22 > --- > > Key: MINVOKER-355 > URL: https://issues.apache.org/jira/browse/MINVOKER-355 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.6.1 > > > PR https://github.com/apache/maven-invoker-plugin/pull/219 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINVOKER-356) Various dependencies update via dependabot see release notes on github
[ https://issues.apache.org/jira/browse/MINVOKER-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-356. - Resolution: Fixed > Various dependencies update via dependabot see release notes on github > -- > > Key: MINVOKER-356 > URL: https://issues.apache.org/jira/browse/MINVOKER-356 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.6.1 > > > see 3.6.1 here https://github.com/apache/maven-invoker-plugin/releases -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINVOKER-356) Various dependencies update via dependabot see release notes on github
Olivier Lamy created MINVOKER-356: - Summary: Various dependencies update via dependabot see release notes on github Key: MINVOKER-356 URL: https://issues.apache.org/jira/browse/MINVOKER-356 Project: Maven Invoker Plugin Issue Type: Task Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.6.1 see 3.6.1 here https://github.com/apache/maven-invoker-plugin/releases -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINVOKER-355) Update 4.0.18 to 4.0.20 to support jdk22
[ https://issues.apache.org/jira/browse/MINVOKER-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINVOKER-355. - Resolution: Fixed > Update 4.0.18 to 4.0.20 to support jdk22 > > > Key: MINVOKER-355 > URL: https://issues.apache.org/jira/browse/MINVOKER-355 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.6.1 > > > PR https://github.com/apache/maven-invoker-plugin/pull/219 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINVOKER-355) Update 4.0.18 to 4.0.20 to support jdk22
Olivier Lamy created MINVOKER-355: - Summary: Update 4.0.18 to 4.0.20 to support jdk22 Key: MINVOKER-355 URL: https://issues.apache.org/jira/browse/MINVOKER-355 Project: Maven Invoker Plugin Issue Type: Task Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.6.1 PR https://github.com/apache/maven-invoker-plugin/pull/219 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINVOKER-352) Remove usage commons-lang3
[ https://issues.apache.org/jira/browse/MINVOKER-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MINVOKER-352: -- Fix Version/s: 3.6.1 (was: 3.x) > Remove usage commons-lang3 > -- > > Key: MINVOKER-352 > URL: https://issues.apache.org/jira/browse/MINVOKER-352 > Project: Maven Invoker Plugin > Issue Type: Improvement >Affects Versions: 3.6.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.6.1 > > > Currently methods / classes of commons-lang3 are used only very few. We can > get rid of the usage. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-79) MBUILDCACHE-67 broke the partial restore process
[
https://issues.apache.org/jira/browse/MBUILDCACHE-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-79.
---
Fix Version/s: 1.2.0
Assignee: Olivier Lamy
Resolution: Fixed
> MBUILDCACHE-67 broke the partial restore process
>
>
> Key: MBUILDCACHE-79
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-79
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Affects Versions: 1.1.0
>Reporter: Amir Hadadi
>Assignee: Olivier Lamy
>Priority: Critical
> Fix For: 1.2.0
>
>
> In MBUILDCACHE-67 a bug was introduced in
> BuildCacheMojosExecutionStrategy#execute. Due to the bug, after a partial
> restore from cache all executions that were restored are executed for the
> second time.
> The bug was introduced by changing:
>
> {code:java}
> boolean restorable = result.isSuccess() || result.isPartialSuccess();
> boolean restored = result.isSuccess(); // if partially restored need to save
> increment
> if (restorable) {
> restored &= restoreProject(result, mojoExecutions, mojoExecutionRunner,
> cacheConfig);
> } else {
> for (MojoExecution mojoExecution : mojoExecutions) {{code}
> to:
>
> {code:java}
> boolean restorable = result.isSuccess() || result.isPartialSuccess();
> boolean restored = result.isSuccess(); // if partially restored need to save
> increment
> if (restorable) {
> CacheRestorationStatus cacheRestorationStatus =
> restoreProject(result, mojoExecutions, mojoExecutionRunner, cacheConfig);
> restored &= CacheRestorationStatus.SUCCESS == cacheRestorationStatus;
> executeExtraCleanPhaseIfNeeded(cacheRestorationStatus, cleanPhase,
> mojoExecutionRunner);
> }
> if (!restored) {
> ...{code}
>
> Since partially restored builds have
> {code:java}
> restored == false{code}
> The
> {code:java}
> if (!restored){code}
> block is always executed, rerunning all the plugins (including the restored
> ones).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-80) Incremental builds with a higher goal than the highest cached goal is rebuilding the full project from scratch
[
https://issues.apache.org/jira/browse/MBUILDCACHE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MBUILDCACHE-80:
---
Assignee: Olivier Lamy
> Incremental builds with a higher goal than the highest cached goal is
> rebuilding the full project from scratch
> --
>
> Key: MBUILDCACHE-80
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-80
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1, 1.1.0, 1.2.0
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\Users\sdkman\candidates\maven\current
> Java version: 21.0.1, vendor: Eclipse Adoptium, runtime:
> C:\Users\sdkman\candidates\java\current
> Default locale: en_US, platform encoding: UTF8
> OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Igor Dianov
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> We are trying to use the Maven build cache extension on a large multi-module
> project with ~180 modules by caching builds in the CI workflows to be able to
> reuse artifacts in the build cache between main and feature branches. The
> final build artifacts (i.e. jar, sources, apidocs) are used to build
> application Docker images and publish Maven modules into Nexus repository
> during deploy phase for releases.
> *Expected Behavior*
> When executing a build for a higher goal then the currently highest cached
> goal, the build extension should skip cached mojo executions, restore the
> cached artifacts (i.e. jar, javadocs, sources) into the project build
> directory and run remaining mojo executions for the increment, i.e. javadocs,
> sources, Docker images between verify -> deploy incremental build. After
> successful completion, the build cache info should be updated to record the
> new highest cached goal with incremental mojo executions and artifacts.
> *Current Behavior*
> When executing a build for a higher goal (i.e. deploy) then the currently
> highest cached goal (i.e. verify), the extension skips cached executions and
> runs mojos between cached and current goals while missing to restore cached
> final artifacts into the project build directory. After that, it runs the
> full build again from the begining to rebuild the artifacts and save build
> cache. Instead of reducing the build time by reusing already packaged
> artifacts and executions, it almost doubles the time to re-run the deploy for
> release from scratch. It also causes the Maven source plugin (3.3.0) to fail
> due to a duplicate sources artifact error, causing the deploy build to fail.
> *Possible Solution*
> It should be possible to restore cached artifacts into project build
> directory while avoiding to re-run full build again after restoring already
> cached mojo executions.
> *Steps to Reproduce*
> 1. Run *mvn clean package -DprojectVersion=1.1.0* from the
> *tests/java/projects/build-extensions* directory.
> {code:java}
> [INFO] Scanning for projects...
> [INFO] Loading cache configuration from
> C:\Users\git\igdianov\maven-build-cache-extension\src\test\projects\build-extension\.mvn\maven-build-cache-config.xml
> [INFO] Using XX hash algorithm for cache
> [INFO]
> [INFO] ---{-}< org.apache.maven.caching.test.simple:simple
> >{-}
> [INFO] Building simple 0.0.1-SNAPSHOT
> [INFO] from pom.xml
> [INFO] ---{-}[ jar
> ]{-}
> [INFO]
> [INFO] — clean:3.2.0:clean (default-clean) @ simple —
> [INFO] Going to calculate checksum for project
> [groupId=org.apache.maven.caching.test.simple, artifactId=simple]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO] Found 1 input files. Project dir processing: 12, plugins: 3 millis
> [INFO] Project inputs calculated in 30 ms. XX checksum [8e6f2406cb760579]
> calculated in 15 ms.
> [INFO] Attempting to restore project
> org.apache.maven.caching.test.simple:simple from build cache
> [INFO] Local build was not found by checksum 8e6f2406cb760579 for
> org.apache.maven.caching.test.simple:simple
> [INFO]
> [INFO] — resources:3.3.1:resources (default-resources) @ simple —
> [WARNING] Using platform encoding (UTF8 actually) to copy filtered resources,
> i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> C:\Users\git\igdianov\maven-build-cache-extension\src\test\projects\build-extension\src\main\resources
> [INFO]
> [INFO] — compiler:3.11.0:compile (default-compile) @ simple —
> [INFO] Changes detected - recompiling the module! :source
>
[jira] [Closed] (MBUILDCACHE-80) Incremental builds with a higher goal than the highest cached goal is rebuilding the full project from scratch
[
https://issues.apache.org/jira/browse/MBUILDCACHE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-80.
---
Resolution: Fixed
> Incremental builds with a higher goal than the highest cached goal is
> rebuilding the full project from scratch
> --
>
> Key: MBUILDCACHE-80
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-80
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1, 1.1.0, 1.2.0
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\Users\sdkman\candidates\maven\current
> Java version: 21.0.1, vendor: Eclipse Adoptium, runtime:
> C:\Users\sdkman\candidates\java\current
> Default locale: en_US, platform encoding: UTF8
> OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Igor Dianov
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> We are trying to use the Maven build cache extension on a large multi-module
> project with ~180 modules by caching builds in the CI workflows to be able to
> reuse artifacts in the build cache between main and feature branches. The
> final build artifacts (i.e. jar, sources, apidocs) are used to build
> application Docker images and publish Maven modules into Nexus repository
> during deploy phase for releases.
> *Expected Behavior*
> When executing a build for a higher goal then the currently highest cached
> goal, the build extension should skip cached mojo executions, restore the
> cached artifacts (i.e. jar, javadocs, sources) into the project build
> directory and run remaining mojo executions for the increment, i.e. javadocs,
> sources, Docker images between verify -> deploy incremental build. After
> successful completion, the build cache info should be updated to record the
> new highest cached goal with incremental mojo executions and artifacts.
> *Current Behavior*
> When executing a build for a higher goal (i.e. deploy) then the currently
> highest cached goal (i.e. verify), the extension skips cached executions and
> runs mojos between cached and current goals while missing to restore cached
> final artifacts into the project build directory. After that, it runs the
> full build again from the begining to rebuild the artifacts and save build
> cache. Instead of reducing the build time by reusing already packaged
> artifacts and executions, it almost doubles the time to re-run the deploy for
> release from scratch. It also causes the Maven source plugin (3.3.0) to fail
> due to a duplicate sources artifact error, causing the deploy build to fail.
> *Possible Solution*
> It should be possible to restore cached artifacts into project build
> directory while avoiding to re-run full build again after restoring already
> cached mojo executions.
> *Steps to Reproduce*
> 1. Run *mvn clean package -DprojectVersion=1.1.0* from the
> *tests/java/projects/build-extensions* directory.
> {code:java}
> [INFO] Scanning for projects...
> [INFO] Loading cache configuration from
> C:\Users\git\igdianov\maven-build-cache-extension\src\test\projects\build-extension\.mvn\maven-build-cache-config.xml
> [INFO] Using XX hash algorithm for cache
> [INFO]
> [INFO] ---{-}< org.apache.maven.caching.test.simple:simple
> >{-}
> [INFO] Building simple 0.0.1-SNAPSHOT
> [INFO] from pom.xml
> [INFO] ---{-}[ jar
> ]{-}
> [INFO]
> [INFO] — clean:3.2.0:clean (default-clean) @ simple —
> [INFO] Going to calculate checksum for project
> [groupId=org.apache.maven.caching.test.simple, artifactId=simple]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO] Found 1 input files. Project dir processing: 12, plugins: 3 millis
> [INFO] Project inputs calculated in 30 ms. XX checksum [8e6f2406cb760579]
> calculated in 15 ms.
> [INFO] Attempting to restore project
> org.apache.maven.caching.test.simple:simple from build cache
> [INFO] Local build was not found by checksum 8e6f2406cb760579 for
> org.apache.maven.caching.test.simple:simple
> [INFO]
> [INFO] — resources:3.3.1:resources (default-resources) @ simple —
> [WARNING] Using platform encoding (UTF8 actually) to copy filtered resources,
> i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> C:\Users\git\igdianov\maven-build-cache-extension\src\test\projects\build-extension\src\main\resources
> [INFO]
> [INFO] — compiler:3.11.0:compile (default-compile) @ simple —
> [INFO] Changes detected - recompiling the module! :source
> [WARNING] File
[jira] [Updated] (MBUILDCACHE-80) Incremental builds with a higher goal than the highest cached goal is rebuilding the full project from scratch
[
https://issues.apache.org/jira/browse/MBUILDCACHE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-80:
Fix Version/s: 1.2.0
> Incremental builds with a higher goal than the highest cached goal is
> rebuilding the full project from scratch
> --
>
> Key: MBUILDCACHE-80
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-80
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.1, 1.1.0, 1.2.0
> Environment: Apache Maven 3.9.6
> (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> Maven home: C:\Users\sdkman\candidates\maven\current
> Java version: 21.0.1, vendor: Eclipse Adoptium, runtime:
> C:\Users\sdkman\candidates\java\current
> Default locale: en_US, platform encoding: UTF8
> OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Igor Dianov
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> We are trying to use the Maven build cache extension on a large multi-module
> project with ~180 modules by caching builds in the CI workflows to be able to
> reuse artifacts in the build cache between main and feature branches. The
> final build artifacts (i.e. jar, sources, apidocs) are used to build
> application Docker images and publish Maven modules into Nexus repository
> during deploy phase for releases.
> *Expected Behavior*
> When executing a build for a higher goal then the currently highest cached
> goal, the build extension should skip cached mojo executions, restore the
> cached artifacts (i.e. jar, javadocs, sources) into the project build
> directory and run remaining mojo executions for the increment, i.e. javadocs,
> sources, Docker images between verify -> deploy incremental build. After
> successful completion, the build cache info should be updated to record the
> new highest cached goal with incremental mojo executions and artifacts.
> *Current Behavior*
> When executing a build for a higher goal (i.e. deploy) then the currently
> highest cached goal (i.e. verify), the extension skips cached executions and
> runs mojos between cached and current goals while missing to restore cached
> final artifacts into the project build directory. After that, it runs the
> full build again from the begining to rebuild the artifacts and save build
> cache. Instead of reducing the build time by reusing already packaged
> artifacts and executions, it almost doubles the time to re-run the deploy for
> release from scratch. It also causes the Maven source plugin (3.3.0) to fail
> due to a duplicate sources artifact error, causing the deploy build to fail.
> *Possible Solution*
> It should be possible to restore cached artifacts into project build
> directory while avoiding to re-run full build again after restoring already
> cached mojo executions.
> *Steps to Reproduce*
> 1. Run *mvn clean package -DprojectVersion=1.1.0* from the
> *tests/java/projects/build-extensions* directory.
> {code:java}
> [INFO] Scanning for projects...
> [INFO] Loading cache configuration from
> C:\Users\git\igdianov\maven-build-cache-extension\src\test\projects\build-extension\.mvn\maven-build-cache-config.xml
> [INFO] Using XX hash algorithm for cache
> [INFO]
> [INFO] ---{-}< org.apache.maven.caching.test.simple:simple
> >{-}
> [INFO] Building simple 0.0.1-SNAPSHOT
> [INFO] from pom.xml
> [INFO] ---{-}[ jar
> ]{-}
> [INFO]
> [INFO] — clean:3.2.0:clean (default-clean) @ simple —
> [INFO] Going to calculate checksum for project
> [groupId=org.apache.maven.caching.test.simple, artifactId=simple]
> [INFO] Scanning plugins configurations to find input files. Probing is
> enabled, values will be checked for presence in file system
> [INFO] Found 1 input files. Project dir processing: 12, plugins: 3 millis
> [INFO] Project inputs calculated in 30 ms. XX checksum [8e6f2406cb760579]
> calculated in 15 ms.
> [INFO] Attempting to restore project
> org.apache.maven.caching.test.simple:simple from build cache
> [INFO] Local build was not found by checksum 8e6f2406cb760579 for
> org.apache.maven.caching.test.simple:simple
> [INFO]
> [INFO] — resources:3.3.1:resources (default-resources) @ simple —
> [WARNING] Using platform encoding (UTF8 actually) to copy filtered resources,
> i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> C:\Users\git\igdianov\maven-build-cache-extension\src\test\projects\build-extension\src\main\resources
> [INFO]
> [INFO] — compiler:3.11.0:compile (default-compile) @ simple —
> [INFO] Changes detected - recompiling the module! :source
> [WARNING] File encoding has not been set,
[jira] [Closed] (MBUILDCACHE-81) Add an option to include project version as part of the cache hash key
[ https://issues.apache.org/jira/browse/MBUILDCACHE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MBUILDCACHE-81. --- Resolution: Fixed > Add an option to include project version as part of the cache hash key > -- > > Key: MBUILDCACHE-81 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Igor Dianov >Assignee: Olivier Lamy >Priority: Major > Labels: pull-request-available > Fix For: 1.2.0 > > > *Current* *Behavior* > The MBUILDCACHE-76 has broken cache reuse between project versions in a > multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 > causes the cache to miss the checksum validation which causes full rebuild of > the project. > *Expected Behavior* > The build cache version normalization should support project version agnostic > caches, so that restoring project from cache avoids repeating expensive tasks > like running tests according to features: > [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] > *Possible Solutions* > * Disable cache for releases if the build requires rebuild due to version > changes. > * Introduce a feature flag configuration to use project version in checksum > calculations for cache invalidation > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-81) Cache portability between project versions is broken due to [MBUILDCACHE-76]
[ https://issues.apache.org/jira/browse/MBUILDCACHE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MBUILDCACHE-81: Fix Version/s: 1.2.0 > Cache portability between project versions is broken due to [MBUILDCACHE-76] > - > > Key: MBUILDCACHE-81 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Igor Dianov >Assignee: Olivier Lamy >Priority: Major > Labels: pull-request-available > Fix For: 1.2.0 > > > *Current* *Behavior* > The MBUILDCACHE-76 has broken cache reuse between project versions in a > multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 > causes the cache to miss the checksum validation which causes full rebuild of > the project. > *Expected Behavior* > The build cache version normalization should support project version agnostic > caches, so that restoring project from cache avoids repeating expensive tasks > like running tests according to features: > [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] > *Possible Solutions* > * Disable cache for releases if the build requires rebuild due to version > changes. > * Introduce a feature flag configuration to use project version in checksum > calculations for cache invalidation > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-81) Cache portability between project versions is broken due to [MBUILDCACHE-76]
[ https://issues.apache.org/jira/browse/MBUILDCACHE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MBUILDCACHE-81: --- Assignee: Olivier Lamy > Cache portability between project versions is broken due to [MBUILDCACHE-76] > - > > Key: MBUILDCACHE-81 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-81 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Igor Dianov >Assignee: Olivier Lamy >Priority: Major > Labels: pull-request-available > > *Current* *Behavior* > The MBUILDCACHE-76 has broken cache reuse between project versions in a > multi-module projects, i.e. changing version from 1.0.0-SNAPSHOT to 1.0.0 > causes the cache to miss the checksum validation which causes full rebuild of > the project. > *Expected Behavior* > The build cache version normalization should support project version agnostic > caches, so that restoring project from cache avoids repeating expensive tasks > like running tests according to features: > [https://maven.apache.org/extensions/maven-build-cache-extension/index.html] > *Possible Solutions* > * Disable cache for releases if the build requires rebuild due to version > changes. > * Introduce a feature flag configuration to use project version in checksum > calculations for cache invalidation > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (MCOMPILER-97) META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error
[ https://issues.apache.org/jira/browse/MCOMPILER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened MCOMPILER-97: --- Reopened per Basil's comment > META-INF/services/javax.annotation.processing.Processor copied before > compilation and causes error > -- > > Key: MCOMPILER-97 > URL: https://issues.apache.org/jira/browse/MCOMPILER-97 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Ubuntu 8.10, JDK 6. >Reporter: Jesse N. Glick >Priority: Major > Attachments: MCOMPILER-97-workaround.zip, maven-6647998-test.zip > > > It is tricky to compile a Maven module which defines a (269-compliant) > annotation processor. If you write the code for the processor in > src/main/java and register it in src/main/resources, > META-INF/services/javax.annotation.processing.Processor is copied to > target/classes first, and then javac is run. But javac is given > target/classes in -classpath, so it tries to load the processor, which of > course has not been compiled yet - a chicken-and-egg problem. > The most straightforward workaround is to specify > -proc:none in your POM. This will only > work, however, if the module does not use any annotation processors defined > in dependencies. If it does, there may be some other trick involving > -processorpath and Maven variable substitution to insert the dependency > classpath. > Switching the order of resources:resources and compiler:compile would help - > at least a clean build would work - though it could still cause problems in > incremental builds. Better would be for the compiler plugin to pass > -processorpath based on the dependency classpath (i.e. -classpath minus > target/classes) when using -source 1.6 or higher. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800027#comment-17800027
]
Olivier Lamy commented on MBUILDCACHE-73:
-
the PR of the linked issue has been merged.
this doesn't fix exactly the title of this issue but could be closed as well.
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-76:
Fix Version/s: 1.2.0
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-76.
---
Resolution: Fixed
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.2.0
>
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MBUILDCACHE-76:
---
Assignee: Olivier Lamy
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-502) checking dependency time from reactor lead to re compiling while it's not needed
[ https://issues.apache.org/jira/browse/MCOMPILER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795135#comment-17795135 ] Olivier Lamy commented on MCOMPILER-502: [~sjaranowski] not anymore a problem (at least for myself :) ) the build cache extension is saving my time for this. > checking dependency time from reactor lead to re compiling while it's not > needed > > > Key: MCOMPILER-502 > URL: https://issues.apache.org/jira/browse/MCOMPILER-502 > Project: Maven Compiler Plugin > Issue Type: New Feature >Affects Versions: 3.10.1 >Reporter: Olivier Lamy >Priority: Major > Fix For: backlog > > > because of this https://issues.apache.org/jira/browse/MDEP-187 or for any > other reasons, some projects need to use `mvn install`. > In such case recompilation is triggered as packaged artifacts from reactor > have a build time > build.startTime. this happen even if there were no > changes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCOMPILER-502) checking dependency time from reactor lead to re compiling while it's not needed
[ https://issues.apache.org/jira/browse/MCOMPILER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCOMPILER-502: --- Fix Version/s: backlog (was: 3.12.0) > checking dependency time from reactor lead to re compiling while it's not > needed > > > Key: MCOMPILER-502 > URL: https://issues.apache.org/jira/browse/MCOMPILER-502 > Project: Maven Compiler Plugin > Issue Type: New Feature >Affects Versions: 3.10.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: backlog > > > because of this https://issues.apache.org/jira/browse/MDEP-187 or for any > other reasons, some projects need to use `mvn install`. > In such case recompilation is triggered as packaged artifacts from reactor > have a build time > build.startTime. this happen even if there were no > changes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MCOMPILER-502) checking dependency time from reactor lead to re compiling while it's not needed
[ https://issues.apache.org/jira/browse/MCOMPILER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MCOMPILER-502: -- Assignee: (was: Olivier Lamy) > checking dependency time from reactor lead to re compiling while it's not > needed > > > Key: MCOMPILER-502 > URL: https://issues.apache.org/jira/browse/MCOMPILER-502 > Project: Maven Compiler Plugin > Issue Type: New Feature >Affects Versions: 3.10.1 >Reporter: Olivier Lamy >Priority: Major > Fix For: backlog > > > because of this https://issues.apache.org/jira/browse/MDEP-187 or for any > other reasons, some projects need to use `mvn install`. > In such case recompilation is triggered as packaged artifacts from reactor > have a build time > build.startTime. this happen even if there were no > changes. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794894#comment-17794894
]
Olivier Lamy edited comment on MBUILDCACHE-73 at 12/9/23 12:56 AM:
---
simply skip test during release:prepare or perform or even both (as your build
has already been validated by a CI?)
regarding your line 1.1-SNAPSHOT, regular build , cache with version Full
Build. Really?? I guess only once after version change or any source change
was (Author: olamy):
simply skip test during release:prepare or perform or even both.
regarding your line 1.1-SNAPSHOT, regular build , cache with version Full
Build. Really?? I guess only once after version change or any source change
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794894#comment-17794894
]
Olivier Lamy commented on MBUILDCACHE-73:
-
simply skip test during release:prepare or perform or even both.
regarding your line 1.1-SNAPSHOT, regular build , cache with version Full
Build. Really?? I guess only once after version change or any source change
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794603#comment-17794603
]
Olivier Lamy commented on MBUILDCACHE-73:
-
[~pdudits] but this will run only once :)
TBH this is the simple (and natural) solution for this.
Maven is always based on gav so why not here as well :)
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MCOMPILER-381) Refactoring needed for isDependencyChanged / Using fileExtensions (AbstractCompilerMojo)
[
https://issues.apache.org/jira/browse/MCOMPILER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MCOMPILER-381.
--
Assignee: Olivier Lamy
Resolution: Fixed
> Refactoring needed for isDependencyChanged / Using fileExtensions
> (AbstractCompilerMojo)
>
>
> Key: MCOMPILER-381
> URL: https://issues.apache.org/jira/browse/MCOMPILER-381
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.12.0
>
>
> The code in the class AbstractCompilerMojo has a method
> {{isDependencyChanged}} which uses the attribute {{fileExtensions}} which is
> being changed within the {{isDependencyChanged}} method. This attribute is
> also being used by the method {{hasNewFile}} which is a kind of confusing (a
> control via a global variable).
> Furthermore a change in {{isDependencyChanged}} where replacing {{".class"}}
> with {{"class"}} results in a [fail which is described here|MCOMPILER-379].
> It should be investigated how this code can be made more clear and maybe
> easier to understand.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-333) Incremental compilation causes "mvn clean compile compile" to fail
[ https://issues.apache.org/jira/browse/MCOMPILER-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCOMPILER-333: --- Fix Version/s: 3.12.0 > Incremental compilation causes "mvn clean compile compile" to fail > -- > > Key: MCOMPILER-333 > URL: https://issues.apache.org/jira/browse/MCOMPILER-333 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.7.0 >Reporter: Anthony Vanelverdinghe >Priority: Major > Fix For: 3.12.0 > > > With true, my build > fails if I do "mvn clean compile compile". From the > [comment|https://issues.apache.org/jira/browse/MCOMPILER-205?focusedCommentId=16390065=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16390065] > in MCOMPILER-205, I understand that incremental compilation deletes the > "classes" directory. But it seems that it doesn't delete the > "generated-sources" directory. > When I do "mvn clean compile" and "mvn compile", the second build fails. > However, if I delete the "generated-sources" directory between the 2 builds, > they both succeed. > So I guess the bug here is that incremental compilation doesn't delete the > "generated-sources" directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-333) Incremental compilation causes "mvn clean compile compile" to fail
[ https://issues.apache.org/jira/browse/MCOMPILER-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCOMPILER-333. -- Resolution: Fixed > Incremental compilation causes "mvn clean compile compile" to fail > -- > > Key: MCOMPILER-333 > URL: https://issues.apache.org/jira/browse/MCOMPILER-333 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.7.0 >Reporter: Anthony Vanelverdinghe >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.12.0 > > > With true, my build > fails if I do "mvn clean compile compile". From the > [comment|https://issues.apache.org/jira/browse/MCOMPILER-205?focusedCommentId=16390065=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16390065] > in MCOMPILER-205, I understand that incremental compilation deletes the > "classes" directory. But it seems that it doesn't delete the > "generated-sources" directory. > When I do "mvn clean compile" and "mvn compile", the second build fails. > However, if I delete the "generated-sources" directory between the 2 builds, > they both succeed. > So I guess the bug here is that incremental compilation doesn't delete the > "generated-sources" directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MCOMPILER-333) Incremental compilation causes "mvn clean compile compile" to fail
[ https://issues.apache.org/jira/browse/MCOMPILER-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MCOMPILER-333: -- Assignee: Olivier Lamy > Incremental compilation causes "mvn clean compile compile" to fail > -- > > Key: MCOMPILER-333 > URL: https://issues.apache.org/jira/browse/MCOMPILER-333 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.7.0 >Reporter: Anthony Vanelverdinghe >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.12.0 > > > With true, my build > fails if I do "mvn clean compile compile". From the > [comment|https://issues.apache.org/jira/browse/MCOMPILER-205?focusedCommentId=16390065=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16390065] > in MCOMPILER-205, I understand that incremental compilation deletes the > "classes" directory. But it seems that it doesn't delete the > "generated-sources" directory. > When I do "mvn clean compile" and "mvn compile", the second build fails. > However, if I delete the "generated-sources" directory between the 2 builds, > they both succeed. > So I guess the bug here is that incremental compilation doesn't delete the > "generated-sources" directory. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793668#comment-17793668
]
Olivier Lamy commented on MBUILDCACHE-73:
-
PR available here https://github.com/apache/maven-build-cache-extension/pull/117
please let us know if this help your use case.
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793523#comment-17793523
]
Olivier Lamy commented on MBUILDCACHE-73:
-
ideally we could simply add the project.version part of the checksum calculation
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793162#comment-17793162
]
Olivier Lamy edited comment on MBUILDCACHE-76 at 12/5/23 7:33 AM:
--
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
this just can be a new configuration option.
regarding forcing install. This is documented
[here|https://maven.apache.org/extensions/maven-build-cache-extension/how-to.html]
using executionControl/runAlways
was (Author: olamy):
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
this just can be a new configuration option.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793162#comment-17793162
]
Olivier Lamy edited comment on MBUILDCACHE-76 at 12/5/23 7:25 AM:
--
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
this just can be a new configuration option.
was (Author: olamy):
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793162#comment-17793162
]
Olivier Lamy commented on MBUILDCACHE-76:
-
`Just add the version to the checksum.`
yes that's a potential solution but this will fix this case but this will
reduce performance for other cases.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17793148#comment-17793148
]
Olivier Lamy commented on MBUILDCACHE-76:
-
`So this will happen for a single module project as well (multi-module is a
distraction). `
nah the problem here is because of the multi module and so projects are part of
the reactor build.
External dependencies checksum calculation is using version because there is
not access to projects inputs (sources, resources etc..).
But here in the case of a multimodule, the reactor give access to the module
buillds inputs (sources, resources etc..) simply because they are part of the
build.
Inter module dependencies (e.g modules part of the same reactor build) doesn't
care (usually) of version change.
project (version 1.0-SNAPSHOT)
- module A (version 1.0-SNAPSHOT)
- module B (version 1.0-SNAPSHOT) using module A (version 1.0-SNAPSHOT)
When building module B the build cache extension can calculate real checksum of
module A because it has direct access to sources, resources etc...
In this case version number doesn't have any impact because the extension can
calculate if something has really change (version number is not real change of
nothing else has changed :) )
BUT in the case of the build need this version as part of the checksum build
input calculation which is the case of m-plugin-p:descriptor goal which use to
generate plugin metadata, we have a problem :)
if you move all the tests modules using your plugin as invoker tests within the
plugin code itself you may not have issues as those tests will not run when
cache detects no changes.
The other workaround now is to disable the cache for the maven plugin
false
or clean local cache entries: rm -rf ~/.m2/build-cache/v1/
Other than that we need to find a solution for maven-plugin type (when it's
part of reactor build) project but something generic.
A solution I tried was to force m-plugin-p to always run
.
descriptor
but nah doesn't work as mvn clean install means deleted target/classes and so
no way to scan for annotations.
the solution could be a new feature to force restore output of a module.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792587#comment-17792587
]
Olivier Lamy commented on MBUILDCACHE-76:
-
We cannot have a full rebuild here as this would break some features of the
build cache project.
The module is part of the reactor and only the version has changed (nothing
else such Java source, dependencies, resources etc..) so the checksum is
exactly the same.
As it's part of the reactor the checksum is calculated versionLess which
perfectly makes sense as again nothing else has changed.
Well here this is generating a problem because of the version used by some
metadata tooling.
We may need something here to manage the case of m-plugin-p:descriptor as it
should run on the restored output from the cache (having a maven-plugin part of
the reactor build for reusing it can lead to other problems)
By the way, the recommended way for testing Maven plugins is to use the
maven-invoker-plugin https://maven.apache.org/plugins/maven-invoker-plugin/
which includes some very features for testing plugins.
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> What should happen is that every module gets rebuilt.
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-76) pom project version change not detected
[
https://issues.apache.org/jira/browse/MBUILDCACHE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792486#comment-17792486
]
Olivier Lamy commented on MBUILDCACHE-76:
-
a temporary workaround is to disable the cache only for the maven-plugin module
Module `openapi-codegen-maven-plugin`
in the properties section:
{{
false
}}
We might need to change the code here in the case of a maven-plugin type and
take into account version when calculating hash for this type.
Or restore the output directory earlier to be able to setup runAlways for
plugin:descriptor
> pom project version change not detected
> ---
>
> Key: MBUILDCACHE-76
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-76
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Dave Moten
>Priority: Minor
>
> When I run `mvn versions:set -DnewVersion=BLAH`, the build cache extension
> does not detect this and skips all modules in a multimodule project (and
> fails when it encounters a module that depends on one of the other modules (a
> maven plugin)).
> To duplicate
> ```
> git clone [https://github.com/davidmoten/openapi-codegen.git]
> cd openapi-codegen
> mvn clean install
> mvn versions:set -DnewVersion=1.2.3.4-SNAPSHOT
> mvn clean install
> ```
> Output:
> ```
> [ERROR] Invalid plugin descriptor for
> com.github.davidmoten:openapi-codegen-maven-plugin:1.2.3.4-SNAPSHOT
> (/home/dave/.m2/build-cache/v1/com.github.davidmoten/openapi-codegen-maven-plugin/ad4e1e854d87f274/local/openapi-codegen-maven-plugin.jar),
> Plugin's descriptor contains the wrong version: 0.1.15-SNAPSHOT -> [Help 1]
> ```
> Here is my maven-build-cache-config.xml:
> ```
> http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.0.0
> [https://maven.apache.org/xsd/build-cache-config-1.0.0.xsd];>
>
> true
>
>
>
>
>
> {{*}.java,{*}.xml,{*}.properties,{*}.mod,*.adoc}
>
> {*}Jenkinsfile{*}
> ./idea/*
>
>
>
> artifactId="maven-surefire-plugin">
>
>
>
> systemPropertyVariables
>
>
>
>
>
>
>
>
>
>
> install
>
>
>
>
> deploy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> skipValue="true"/>
>
>
>
>
>
>
>
>
>
> ```
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-50) Unsupported phase: null with dependency:analyze in multimodule project
[
https://issues.apache.org/jira/browse/MBUILDCACHE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-50:
Fix Version/s: (was: 1.1.0)
> Unsupported phase: null with dependency:analyze in multimodule project
> --
>
> Key: MBUILDCACHE-50
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-50
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 x64
> Maven 3.9.1
> Java 20 (Eclipse Adoptium)
>Reporter: Thorsten Heit
>Priority: Major
> Attachments: pomtest.tar.bz2
>
>
> Executing {{"mvn dependency:analyze"}} results in an error message
> "Unsupported phase: null" when the first submodule of a multimodule project
> is being analyzed.
> I've attached a very simple project that can be used to demonstrate the
> behaviour: As long as the {{.mvn}} folder exists and the build cache
> extension is active, executing {{"mvn dependency:analyze"}} or {{"mvn
> dependency:3.5.0:analyze"}} don't work. Rename the folder => works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-50) Unsupported phase: null with dependency:analyze in multimodule project
[
https://issues.apache.org/jira/browse/MBUILDCACHE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-50:
Fix Version/s: 1.2.0
> Unsupported phase: null with dependency:analyze in multimodule project
> --
>
> Key: MBUILDCACHE-50
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-50
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: Windows 10 x64
> Maven 3.9.1
> Java 20 (Eclipse Adoptium)
>Reporter: Thorsten Heit
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: pomtest.tar.bz2
>
>
> Executing {{"mvn dependency:analyze"}} results in an error message
> "Unsupported phase: null" when the first submodule of a multimodule project
> is being analyzed.
> I've attached a very simple project that can be used to demonstrate the
> behaviour: As long as the {{.mvn}} folder exists and the build cache
> extension is active, executing {{"mvn dependency:analyze"}} or {{"mvn
> dependency:3.5.0:analyze"}} don't work. Rename the folder => works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-75) Upgrade Maven parent 41
[ https://issues.apache.org/jira/browse/MBUILDCACHE-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MBUILDCACHE-75. --- Resolution: Fixed > Upgrade Maven parent 41 > --- > > Key: MBUILDCACHE-75 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-75 > Project: Maven Build Cache Extension > Issue Type: Task >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Minor > Labels: pull-request-available > Fix For: 1.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-75) Upgrade Maven parent 41
Olivier Lamy created MBUILDCACHE-75: --- Summary: Upgrade Maven parent 41 Key: MBUILDCACHE-75 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-75 Project: Maven Build Cache Extension Issue Type: Task Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 1.1.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-74) Old POM builds are not cleaned up from local cache
[ https://issues.apache.org/jira/browse/MBUILDCACHE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MBUILDCACHE-74. --- Assignee: Olivier Lamy Resolution: Fixed > Old POM builds are not cleaned up from local cache > -- > > Key: MBUILDCACHE-74 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-74 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.0.1 >Reporter: Michael Weirauch >Assignee: Olivier Lamy >Priority: Minor > Labels: pull-request-available > > We are operating a multi-module mono repository with an in-tree parent which > is used by all modules. The parent is modified regularly. While debugging I > realized that stale cache entries for the parent are still present in the > local build cache directory allthough "maxBuildsCached" is set to "1". > I have a fix ready, but I am still trying to figure if I can hook into an > existing test or create a dedicated one. (I am not that familiar with the > codebase.) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-417) Create HTTP test suite a la "TCK"
[ https://issues.apache.org/jira/browse/MRESOLVER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1467#comment-1467 ] Olivier Lamy commented on MRESOLVER-417: I agree on the Wagon TCK using is old tech and needs some rewrite. What I see such https://github.com/apache/maven-resolver/blob/b1196275b78ad7e2c7ce11263177f8a19e43a62c/maven-resolver-transport-jdk-parent/maven-resolver-transport-jdk-8/src/main/java/org/eclipse/aether/transport/jdk/JdkTransporterFactory.java or https://github.com/apache/maven-resolver/blob/b1196275b78ad7e2c7ce11263177f8a19e43a62c/maven-resolver-transport-jetty-parent/maven-resolver-transport-jetty-9/src/main/java/org/eclipse/aether/transport/jetty/JettyTransporterFactory.java looks like empty code but still to maintain in the future, which makes the architecture (too much?) complex and very complicated to understand. > Create HTTP test suite a la "TCK" > - > > Key: MRESOLVER-417 > URL: https://issues.apache.org/jira/browse/MRESOLVER-417 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Now that we have 3 (4 w/ Wagon) HTTP capable resolver transports, we need > some common reusable across HTTP Transports test suite, probably w/ "tunable" > features. > Requirements aside of "most basic functionality": > * MRESOLVER-396 Back off > * MRESOLVER-393 Retain last modified (on files) > * MRESOLVER-382 Setting outgoing interface > * MRESOLVER-361 Unreliable TCP and retries > * MRESOLVER-347 and MRESOLVER-348 Pool controls, reuse connection, max TTL > * MRESOLVER-339 and MRESOLVER-315 Preemptive auth > * MRESOLVER-341 Preemptive PUT auth > * MRESOLVER-328 SSL insecure mode > * MRESOLVER-326 Retries on certain errors > The test should use _standard Resolver configuration with different > transports_ as described on page > https://maven.apache.org/resolver/configuration.html > Hence, testing of Wagon is out of scope, as it uses totally different, > ancient Plexus-XML based configuration, does not obey standard resolver > configuration properties. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy resolved MBUILDCACHE-61.
-
Assignee: Olivier Lamy
Resolution: Fixed
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Assignee: Olivier Lamy
>Priority: Major
> Labels: documentation
> Fix For: 1.1.0
>
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Closed] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-61.
---
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Assignee: Olivier Lamy
>Priority: Major
> Labels: documentation
> Fix For: 1.1.0
>
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Updated] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-61:
Fix Version/s: 1.1.0
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: documentation
> Fix For: 1.1.0
>
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Comment Edited] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774282#comment-17774282
]
Olivier Lamy edited comment on MBUILDCACHE-61 at 10/12/23 1:00 AM:
---
Add `--add-opens java.base/sun.nio.ch=ALL-UNNAMED` in .mvn/jvm.config file
documentation added here
https://github.com/apache/maven-build-cache-extension/commit/9a842bde58d49cf0294be6de9868dceb0eae8aa6#diff-ecb4b6db7bc09c2b02435d07c165dfb8d3cdcfb648e577e4e0d3f696846a096aR37
was (Author: olamy):
Add `--add-opens java.base/sun.nio.ch=ALL-UNNAMED` in .mvn/jvm.config file
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: documentation
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
>
[jira] [Commented] (MBUILDCACHE-61) XXMM hash algorithm does not work on Java 17
[
https://issues.apache.org/jira/browse/MBUILDCACHE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774282#comment-17774282
]
Olivier Lamy commented on MBUILDCACHE-61:
-
Add `--add-opens java.base/sun.nio.ch=ALL-UNNAMED` in .mvn/jvm.config file
> XXMM hash algorithm does not work on Java 17
>
>
> Key: MBUILDCACHE-61
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-61
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Reporter: Benjamin Marwell
>Priority: Major
> Labels: documentation
>
> h2. Actual behaviour
> When trying to use XXMM, I get this error:
> {code:java}
> $ ./mvnw compile -Dmaven.build.cache.remote.save.enabled=true
> -Daether.connector.http.supportWebDav=true[INFO] Loading cache configuration
> from $HOME/Projects/git/my-app/.mvn/maven-build-cache-config.xml
> [INFO] Using XXMM hash algorithm for cache
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [...]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.386 s
> [INFO] Finished at: 2023-06-12T11:58:13+02:00
> [INFO]
>
> [INFO] Saving cache report on build completion
> [INFO] Saved to remote cache
> dav:http://my-server:8049/build-cache/my-app//v1/my-app.my-module/my-module/e1e4d804-879d-4d73-bbaa-b5ce13f77a39/build-cache-report.xml
> ---
> constituent[0]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/conf/logging/
> constituent[1]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/httpcore-4.4.16.jar
> constituent[2]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-utils-3.5.1.jar
> constituent[3]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-component-annotations-2.1.0.jar
> constituent[4]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-sec-dispatcher-2.0.jar
> constituent[5]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/slf4j-api-1.7.36.jar
> constituent[6]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-settings-3.9.2.jar
> constituent[7]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/aopalliance-1.0.jar
> constituent[8]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-3.9.2.jar
> constituent[9]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-spi-1.9.10.jar
> constituent[10]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/javax.annotation-api-1.3.2.jar
> constituent[11]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-embedder-3.9.2.jar
> constituent[12]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-connector-basic-1.9.10.jar
> constituent[13]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-named-locks-1.9.10.jar
> constituent[14]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/commons-cli-1.5.0.jar
> constituent[15]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-model-builder-3.9.2.jar
> constituent[16]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/wagon-http-3.5.3.jar
> constituent[17]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-interpolation-1.26.jar
> constituent[18]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/plexus-cipher-2.0.jar
> constituent[19]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-api-1.9.10.jar
> constituent[20]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-transport-file-1.9.10.jar
> constituent[21]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/guice-5.1.0.jar
> constituent[22]:
> file:$HOME/.m2/wrapper/dists/apache-maven-3.9.2-bin/507e2f6e/apache-maven-3.9.2/lib/maven-resolver-impl-1.9.10.jar
> constituent[23]:
>
[jira] [Closed] (MBUILDCACHE-63) Remote cache with Nexus raw repository does not work
[
https://issues.apache.org/jira/browse/MBUILDCACHE-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-63.
---
Assignee: Olivier Lamy
Resolution: Not A Problem
not an issue
> Remote cache with Nexus raw repository does not work
>
>
> Key: MBUILDCACHE-63
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-63
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Components: remote build cache
>Affects Versions: 1.0.1
> Environment: Apache Maven 3.9.2
> (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
> Maven home: /opt/maven/apache-maven
> Java version: 19.0.2, vendor: Eclipse Adoptium, runtime:
> /opt/java/jdk-19.0.2+7
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux", version: "5.19.0-43-generic", arch: "amd64", family: "unix"
>Reporter: Ben Tatham
>Assignee: Olivier Lamy
>Priority: Major
>
> I set up a raw repository in Sonatype Nexus to use as the remote build cache.
> It seems to connect ok, but the it gets a 404 when looking for the build
> cache, and then does not seem to even attempt uploading it when the build is
> complete (even though it does save the build cache locally). I assume this
> means that the exception at start of the build is disabling the remote cache
> being saved later in the build.
> I have tried it with and without `dav:` prefix on the url, with same result.
> -X gives no further details that I can see.
> Let me know if there is anything else I can do to debug this.
> {{[INFO] Attempting to restore project
> ca.nanometrics.apollo.server:apollo-server-parent from build cache}}
> {{[INFO] Downloading
> dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}}
> {{[INFO] Cannot download
> dav:[https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml]}}
> {{org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at
> [https://*/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml|https://%2A%2A%2A%2A%2A/repository/build-cache/v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml],
> status: 404
> v1/ca.nanometrics.apollo.server/apollo-server-parent/db1314745382ad8b/buildinfo.xml}}
> {{ at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1191)}}
> {{ at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)}}
> {{ at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)}}
> {{ at org.apache.maven.wagon.StreamWagon.getIfNewerToStream
> (StreamWagon.java:226)}}
> {{ at org.apache.maven.wagon.StreamWagon.getToStream
> (StreamWagon.java:262)}}
> {{ at
> org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:427)}}
> {{ at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:367)}}
> {{ at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:348)}}
> {{ at
> org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent
> (RemoteCacheRepositoryImpl.java:151)}}
> {{ at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild
> (RemoteCacheRepositoryImpl.java:108)}}
> {{ at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild
> (LocalCacheRepositoryImpl.java:169)}}
> {{ at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:207)}}
> {{ at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:180)}}
> {{ at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:117)}}
> {{ at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:160)}}
> {{ 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)}}
> {{
[jira] [Closed] (MBUILDCACHE-32) Do not print exception when probing builds in remote repo
[
https://issues.apache.org/jira/browse/MBUILDCACHE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-32.
---
> Do not print exception when probing builds in remote repo
> -
>
> Key: MBUILDCACHE-32
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-32
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Alexander Ashitkin
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.1.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When cache engine tries to discover existing cache by checksum, it sends get
> request.
> This request is normally getting 404s, because cache is not guaranteed to
> exist.
> It's a normal situation and exception should not be printed in such case as
> it meaninglessly pollutes logs:
> {code:java}
> org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at
> https://my-cache/.../buildinfo.xml, status: 404 Not Found
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1191)
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewerToStream
> (StreamWagon.java:226)
> at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:533)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:425)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:400)
> at
> org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent
> (RemoteCacheRepositoryImpl.java:165)
> at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild
> (RemoteCacheRepositoryImpl.java:114)
> at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild
> (LocalCacheRepositoryImpl.java:183)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:212)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:179)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:114)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:179)
> {code}
> {{Need to create method similar to
> RemoteCacheRepositoryImpl#getResourceContent, but }}{{getResourceContentQuiet
> and use it when probing buildinfo.xml. the method should not log exceptions}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MBUILDCACHE-32) Do not print exception when probing builds in remote repo
[
https://issues.apache.org/jira/browse/MBUILDCACHE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy resolved MBUILDCACHE-32.
-
Assignee: Olivier Lamy
Resolution: Fixed
> Do not print exception when probing builds in remote repo
> -
>
> Key: MBUILDCACHE-32
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-32
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Alexander Ashitkin
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.1.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When cache engine tries to discover existing cache by checksum, it sends get
> request.
> This request is normally getting 404s, because cache is not guaranteed to
> exist.
> It's a normal situation and exception should not be printed in such case as
> it meaninglessly pollutes logs:
> {code:java}
> org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at
> https://my-cache/.../buildinfo.xml, status: 404 Not Found
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1191)
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewerToStream
> (StreamWagon.java:226)
> at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:533)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:425)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:400)
> at
> org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent
> (RemoteCacheRepositoryImpl.java:165)
> at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild
> (RemoteCacheRepositoryImpl.java:114)
> at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild
> (LocalCacheRepositoryImpl.java:183)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:212)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:179)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:114)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:179)
> {code}
> {{Need to create method similar to
> RemoteCacheRepositoryImpl#getResourceContent, but }}{{getResourceContentQuiet
> and use it when probing buildinfo.xml. the method should not log exceptions}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (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:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-67.
---
> 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
> Fix For: 1.1.0
>
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.629 s
> [INFO] Finished at: 2023-08-02T23:21:36+02:00
> [INFO]
>
> [DEBUG] Save cache-report to local file:
> C:\Users\kbuntrock\Developpement\sample\target\maven-incremental\cache-report.662d75e1-1a0e-407a-85aa-21da4d207498.xml
> {code}
> While trying to reproduce the error with a more convenient use case, it seems
> that erasing the artefact from the repository (local in my case) does
[jira] [Updated] (MBUILDCACHE-32) Do not print exception when probing builds in remote repo
[
https://issues.apache.org/jira/browse/MBUILDCACHE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-32:
Fix Version/s: 1.1.0
> Do not print exception when probing builds in remote repo
> -
>
> Key: MBUILDCACHE-32
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-32
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Alexander Ashitkin
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.1.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When cache engine tries to discover existing cache by checksum, it sends get
> request.
> This request is normally getting 404s, because cache is not guaranteed to
> exist.
> It's a normal situation and exception should not be printed in such case as
> it meaninglessly pollutes logs:
> {code:java}
> org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at
> https://my-cache/.../buildinfo.xml, status: 404 Not Found
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1191)
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewerToStream
> (StreamWagon.java:226)
> at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:533)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:425)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:400)
> at
> org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent
> (RemoteCacheRepositoryImpl.java:165)
> at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild
> (RemoteCacheRepositoryImpl.java:114)
> at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild
> (LocalCacheRepositoryImpl.java:183)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:212)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:179)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:114)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:179)
> {code}
> {{Need to create method similar to
> RemoteCacheRepositoryImpl#getResourceContent, but }}{{getResourceContentQuiet
> and use it when probing buildinfo.xml. the method should not log exceptions}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (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:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-67:
Fix Version/s: 1.1.0
> 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
> Fix For: 1.1.0
>
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.629 s
> [INFO] Finished at: 2023-08-02T23:21:36+02:00
> [INFO]
>
> [DEBUG] Save cache-report to local file:
> C:\Users\kbuntrock\Developpement\sample\target\maven-incremental\cache-report.662d75e1-1a0e-407a-85aa-21da4d207498.xml
> {code}
> While trying to reproduce the error with a more convenient use case, it seems
> that erasing the artefact from the
[jira] [Resolved] (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:all-tabpanel
]
Olivier Lamy resolved MBUILDCACHE-67.
-
Resolution: Fixed
> 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
> Fix For: 1.1.0
>
>
> If any error arise during the restoration of artefacts from the cache, the
> build should continue as it would usually do without the cache. In fact, it's
> even what the extension says "Cannot restore cache, continuing with normal
> build."
> But it's a lie, the build goes straight to the phase where it saves the
> generated artefact in cache. ;)
> {code:java}
> [DEBUG] Hash calculated, item: dependency, hash: 14eab0591a006938
> [INFO] Project inputs calculated in 97 ms. XX checksum [a0d7876d9bceb494]
> calculated in 50 ms.
> [INFO] Attempting to restore project
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from build cache
> [DEBUG] Checking local build info:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO] Local build found by checksum a0d7876d9bceb494
> [INFO] Found cached build, restoring
> io.github.kbuntrock.sample:openapi-plugin-sample-backend from cache by
> checksum a0d7876d9bceb494
> [DEBUG] Cached build details:
> Build{dto=org.apache.maven.buildcache.xml.build.Build@63cf9de0}
> [DEBUG] Cannot restore cache, continuing with normal build.
> java.lang.RuntimeException: Made-up error : restoring artefact is impossible.
> at
> org.apache.maven.buildcache.CacheControllerImpl.restoreProjectArtifacts
> (CacheControllerImpl.java:312)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:171)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:124)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> [INFO] Cannot restore project artifacts, continuing with non cached build
> [INFO] Saved Build to local file:
> C:\Users\kbuntrock\.m2\build-cache\v1\io.github.kbuntrock.sample\openapi-plugin-sample-backend\a0d7876d9bceb494\local\buildinfo.xml
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.629 s
> [INFO] Finished at: 2023-08-02T23:21:36+02:00
> [INFO]
>
> [DEBUG] Save cache-report to local file:
> C:\Users\kbuntrock\Developpement\sample\target\maven-incremental\cache-report.662d75e1-1a0e-407a-85aa-21da4d207498.xml
> {code}
> While trying to reproduce the error with a more convenient use case, it seems
> that erasing the artefact from the
[jira] [Closed] (MBUILDCACHE-64) Apply global exclusions to folder names
[
https://issues.apache.org/jira/browse/MBUILDCACHE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-64.
---
> 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)
[jira] [Resolved] (MBUILDCACHE-64) Apply global exclusions to folder names
[
https://issues.apache.org/jira/browse/MBUILDCACHE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy resolved MBUILDCACHE-64.
-
Resolution: Fixed
Thanks for the PR
> 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)
[jira] [Assigned] (MBUILDCACHE-64) Apply global exclusions to folder names
[
https://issues.apache.org/jira/browse/MBUILDCACHE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MBUILDCACHE-64:
---
Assignee: Olivier Lamy
> 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)
[jira] [Updated] (MBUILDCACHE-64) Apply global exclusions to folder names
[
https://issues.apache.org/jira/browse/MBUILDCACHE-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-64:
Fix Version/s: 1.1.0
> 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
>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)
[jira] [Closed] (MBUILDCACHE-66) Mojo execution can be out of scope
[
https://issues.apache.org/jira/browse/MBUILDCACHE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-66.
---
Resolution: Fixed
> Mojo execution can be out of scope
> --
>
> Key: MBUILDCACHE-66
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-66
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Affects Versions: 1.0.0, 1.0.1
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.1.0
>
>
> Issue while using the cache:
> {code}
> ERROR] Cannot get configured mojo: Unable to load the mojo 'process-asciidoc'
> (or one of its required components) from the plugin
> 'org.asciidoctor:asciidoctor-maven-plugin:2.2.4':
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> [ERROR]
> [ERROR] 1) [Guice/ErrorInCustomProvider]: OutOfScopeException: Cannot access
> Key[type=MavenProject, annotation=[none]] outside of a scoping block
> [ERROR] at
> MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:47)
> [ERROR] \_ installed by: WireModule -> MojoExecutionScopeModule
> [ERROR] at AsciidoctorMojo.project(AsciidoctorMojo.java:46)
> [ERROR] \_ for field project
> [ERROR] while locating AsciidoctorMojo
> [ERROR] at
> ClassRealm[plugin>org.asciidoctor:asciidoctor-maven-plugin:2.2.4, parent:
> ClassLoaders$AppClassLoader@5ffd2b27]
> [ERROR] \_ installed by: WireModule -> PlexusBindingModule
> [ERROR] while locating Mojo annotated with
> @Named("org.asciidoctor:asciidoctor-maven-plugin:2.2.4:process-asciidoc")
> [ERROR]
> [ERROR] Learn more:
> [ERROR] https://github.com/google/guice/wiki/ERROR_IN_CUSTOM_PROVIDER
> [ERROR]
> [ERROR] 1 error
> [ERROR]
> [ERROR] ==
> [ERROR] Full classname legend:
> [ERROR] ==
> [ERROR] AsciidoctorMojo: "org.asciidoctor.maven.AsciidoctorMojo"
> [ERROR] ClassLoaders$AppClassLoader:
> "jdk.internal.loader.ClassLoaders$AppClassLoader"
> [ERROR] MavenProject:"org.apache.maven.project.MavenProject"
> [ERROR] Mojo:"org.apache.maven.plugin.Mojo"
> [ERROR] MojoExecutionScopeModule:
> "org.apache.maven.execution.scope.internal.MojoExecutionScopeModule"
> [ERROR] Named: "com.google.inject.name.Named"
> [ERROR] OutOfScopeException: "com.google.inject.OutOfScopeException"
> [ERROR] PlexusBindingModule:
> "org.eclipse.sisu.plexus.PlexusBindingModule"
> [ERROR] WireModule: "org.eclipse.sisu.wire.WireModule"
> [ERROR]
> [ERROR] End of classname legend:
> [ERROR]
> [ERROR]
> [ERROR] role: org.apache.maven.plugin.Mojo
> [ERROR] roleHint:
> org.asciidoctor:asciidoctor-maven-plugin:2.2.4:process-asciidoc: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Cannot get configured
> mojo
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.verifyCacheConsistency
> (BuildCacheMojosExecutionStrategy.java:246)
> at
> org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.restoreProject
> (BuildCacheMojosExecutionStrategy.java:184)
> 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.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:104)
> at java.lang.reflect.Method.invoke (Method.java:578)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at
[jira] [Comment Edited] (MSOURCES-121) Check for duplicated addition of the same file
[ https://issues.apache.org/jira/browse/MSOURCES-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749379#comment-17749379 ] Olivier Lamy edited comment on MSOURCES-121 at 8/1/23 12:59 AM: not even sure we need this test now because of https://issues.apache.org/jira/browse/MNG-5868 oh but this https://issues.apache.org/jira/browse/MNG-7316 by the way I have created this https://issues.apache.org/jira/browse/MSOURCES-141 was (Author: olamy): not even sure we need this test now because of https://issues.apache.org/jira/browse/MNG-5868 by the way I have created this https://issues.apache.org/jira/browse/MSOURCES-141 > Check for duplicated addition of the same file > -- > > Key: MSOURCES-121 > URL: https://issues.apache.org/jira/browse/MSOURCES-121 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.3.0 > > > By configuring the execution of maven-source-plugin twice you can fail the > build during a release only which is annoying for users. > We need to check if we could identify the duplicate execution of > maven-source-plugin and producing the same files twice...If we identify such > situation we should fail the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSOURCES-121) Check for duplicated addition of the same file
[ https://issues.apache.org/jira/browse/MSOURCES-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17749379#comment-17749379 ] Olivier Lamy commented on MSOURCES-121: --- not even sure we need this test now because of https://issues.apache.org/jira/browse/MNG-5868 by the way I have created this https://issues.apache.org/jira/browse/MSOURCES-141 > Check for duplicated addition of the same file > -- > > Key: MSOURCES-121 > URL: https://issues.apache.org/jira/browse/MSOURCES-121 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.0.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.3.0 > > > By configuring the execution of maven-source-plugin twice you can fail the > build during a release only which is annoying for users. > We need to check if we could identify the duplicate execution of > maven-source-plugin and producing the same files twice...If we identify such > situation we should fail the build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
