[jira] [Closed] (MJLINK-83) Allow adding multiple launchers to a jlink'ed image
[
https://issues.apache.org/jira/browse/MJLINK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MJLINK-83.
--
Resolution: Fixed
Thanks for your contribution
> Allow adding multiple launchers to a jlink'ed image
> ---
>
> Key: MJLINK-83
> URL: https://issues.apache.org/jira/browse/MJLINK-83
> Project: Maven JLink Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.0
> Environment: (applies to all platforms)
>Reporter: Peter Hull
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
>
> The {{jlink}} command line tool allows the {{--launcher}} argument to be
> specified multiple times to create multiple launcher scripts in the image.
> However the maven plugin only passes on one {{}} element from its
> configuration section to the tool. If multiple are specified, the last one
> takes precedence. I would like to improve this so the plugin will pass
> multiple launcher specs on to the {{jlink}} tool. I suggest the config should
> look like:
> {noformat}
> command=module/main{noformat}
> (as before, for backward compatibility and the common case where there is
> only one)
> or
>
> {noformat}
>
> command1=module1/main1
> command2=module2/main2
> ...
>
> {noformat}
>
> where {{}} can contain zero or more {{}} elements with
> the same syntax as the existing element.
> One remaining question - what do do if the config specifies both
> {{}} and {{}} - combine the two or signal an error?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJLINK-83) Allow adding multiple launchers to a jlink'ed image
[
https://issues.apache.org/jira/browse/MJLINK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MJLINK-83:
---
Fix Version/s: 3.3.0
> Allow adding multiple launchers to a jlink'ed image
> ---
>
> Key: MJLINK-83
> URL: https://issues.apache.org/jira/browse/MJLINK-83
> Project: Maven JLink Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.0
> Environment: (applies to all platforms)
>Reporter: Peter Hull
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.3.0
>
>
> The {{jlink}} command line tool allows the {{--launcher}} argument to be
> specified multiple times to create multiple launcher scripts in the image.
> However the maven plugin only passes on one {{}} element from its
> configuration section to the tool. If multiple are specified, the last one
> takes precedence. I would like to improve this so the plugin will pass
> multiple launcher specs on to the {{jlink}} tool. I suggest the config should
> look like:
> {noformat}
> command=module/main{noformat}
> (as before, for backward compatibility and the common case where there is
> only one)
> or
>
> {noformat}
>
> command1=module1/main1
> command2=module2/main2
> ...
>
> {noformat}
>
> where {{}} can contain zero or more {{}} elements with
> the same syntax as the existing element.
> One remaining question - what do do if the config specifies both
> {{}} and {{}} - combine the two or signal an error?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MJLINK-83) Allow adding multiple launchers to a jlink'ed image
[
https://issues.apache.org/jira/browse/MJLINK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MJLINK-83:
--
Assignee: Olivier Lamy
> Allow adding multiple launchers to a jlink'ed image
> ---
>
> Key: MJLINK-83
> URL: https://issues.apache.org/jira/browse/MJLINK-83
> Project: Maven JLink Plugin
> Issue Type: Improvement
>Affects Versions: 3.2.0
> Environment: (applies to all platforms)
>Reporter: Peter Hull
>Assignee: Olivier Lamy
>Priority: Minor
>
> The {{jlink}} command line tool allows the {{--launcher}} argument to be
> specified multiple times to create multiple launcher scripts in the image.
> However the maven plugin only passes on one {{}} element from its
> configuration section to the tool. If multiple are specified, the last one
> takes precedence. I would like to improve this so the plugin will pass
> multiple launcher specs on to the {{jlink}} tool. I suggest the config should
> look like:
> {noformat}
> command=module/main{noformat}
> (as before, for backward compatibility and the common case where there is
> only one)
> or
>
> {noformat}
>
> command1=module1/main1
> command2=module2/main2
> ...
>
> {noformat}
>
> where {{}} can contain zero or more {{}} elements with
> the same syntax as the existing element.
> One remaining question - what do do if the config specifies both
> {{}} and {{}} - combine the two or signal an error?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-100) Exclude example incorrect in docs - Performance
[
https://issues.apache.org/jira/browse/MBUILDCACHE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-100:
-
Fix Version/s: 1.3.0
> Exclude example incorrect in docs - Performance
> ---
>
> Key: MBUILDCACHE-100
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-100
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Brian Demers
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.3.0
>
>
> On the performance page, the "Filter out unnecessary artifacts", example is
> missing the wrapping "patterns" node.
>
> It should be:
> {code:java}
>
>
>
>
> .*\.zip
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-100) Exclude example incorrect in docs - Performance
[
https://issues.apache.org/jira/browse/MBUILDCACHE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-100.
Assignee: Olivier Lamy
Resolution: Fixed
> Exclude example incorrect in docs - Performance
> ---
>
> Key: MBUILDCACHE-100
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-100
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Brian Demers
>Assignee: Olivier Lamy
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.3.0
>
>
> On the performance page, the "Filter out unnecessary artifacts", example is
> missing the wrapping "patterns" node.
>
> It should be:
> {code:java}
>
>
>
>
> .*\.zip
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-99) Project checksum fails to identify moved files in certain cases
[ https://issues.apache.org/jira/browse/MBUILDCACHE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MBUILDCACHE-99: Fix Version/s: 1.3.0 > Project checksum fails to identify moved files in certain cases > --- > > Key: MBUILDCACHE-99 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-99 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Amir Hadadi >Priority: Major > Labels: pull-request-available > Fix For: 1.3.0 > > > Input files checksum is calculated by sorting all files and using their > content (but not their path) to update a checksum. > Let's say that there are 2 files named A,B and B gets renamed to C. Since the > order of the files didn't change and the contents of the files didn't change, > the input files checksum remains the same. > The solution is to include the normalized file path in the file checksum > calculation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-99) Project checksum fails to identify moved files in certain cases
[ https://issues.apache.org/jira/browse/MBUILDCACHE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MBUILDCACHE-99. --- Assignee: Olivier Lamy Resolution: Fixed > Project checksum fails to identify moved files in certain cases > --- > > Key: MBUILDCACHE-99 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-99 > Project: Maven Build Cache Extension > Issue Type: Bug >Affects Versions: 1.2.0 >Reporter: Amir Hadadi >Assignee: Olivier Lamy >Priority: Major > Labels: pull-request-available > Fix For: 1.3.0 > > > Input files checksum is calculated by sorting all files and using their > content (but not their path) to update a checksum. > Let's say that there are 2 files named A,B and B gets renamed to C. Since the > order of the files didn't change and the contents of the files didn't change, > the input files checksum remains the same. > The solution is to include the normalized file path in the file checksum > calculation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MBUILDCACHE-87.
---
Resolution: Fixed
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.3.0
>
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17865853#comment-17865853
]
Olivier Lamy commented on MBUILDCACHE-87:
-
PR merged.
Thanks for your hard work and patience :)
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.3.0
>
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MBUILDCACHE-87:
---
Assignee: Olivier Lamy
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Assignee: Olivier Lamy
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.3.0
>
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-87) Checksum should consider plugin dependencies
[
https://issues.apache.org/jira/browse/MBUILDCACHE-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MBUILDCACHE-87:
Fix Version/s: 1.3.0
> Checksum should consider plugin dependencies
>
>
> Key: MBUILDCACHE-87
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-87
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Reporter: Réda Housni Alaoui
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.3.0
>
>
> I have a multi module project where module A is used as a dependency of
> maven-dependency-plugin:unpack declared in module B.
> {{buildinfo.xml}} of module B does not consider module A as a dependency.
> Maybe something similar to
> https://github.com/apache/maven-build-cache-extension/blob/6eb05e61fdfa7be1ad44cf6afc13958b0c6ea4a6/src/main/java/org/apache/maven/buildcache/checksum/MavenProjectInput.java#L602
> should be added for plugin dependencies?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8116) Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attribute
[
https://issues.apache.org/jira/browse/MNG-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MNG-8116.
-
Resolution: Fixed
> Plugin configuration can randomly fail in case of method overloading as it
> doesn't take into account implementation attribute
> -
>
> 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: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> 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] [Commented] (MNG-8116) Plugin configuration can randomly fail in case of method overloading as it doesn't take into account implementation attribute
[
https://issues.apache.org/jira/browse/MNG-8116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852613#comment-17852613
]
Olivier Lamy commented on MNG-8116:
---
I have tested with the reproducer from
[https://github.com/jetty/jetty.project/issues/11732] and couldn't reproduce
the problem after a lot builds
> Plugin configuration can randomly fail in case of method overloading as it
> doesn't take into account implementation attribute
> -
>
> 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: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> 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] [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)}}
> {{
