Maven 构建缓存扩展重复缓存步骤

问题描述 投票:0回答:1

我正在尝试使用 Maven 构建缓存扩展来缓存一个 Maven 命令的结果,以便在另一个命令中使用。例如:

./mvnw clean compile
./mvnw test          # Should use cached compile
./mvnw package       # Should use cached compile and test
./mvnw verify        # Should use cached compile, test, and package
./mvnw install       # Should use cached compile, test, package, and verify
./mvnw deploy        # Should use cached compile, test, package, verify, and install

但是,当我像这样连续运行命令时,我注意到它会从上一个命令停止的位置继续开始,但随后它会返回并从头开始运行 Maven 生命周期。考虑运行

./mvnw install
./mvnw verify
的输出。它使用之前缓存的步骤并直接跳转到安装,正如人们所期望的那样,但安装完成后,它会从编译阶段重新开始 Maven 生命周期。

[INFO] --------------< com.example:foo-core >---------------
[INFO] Building foo-core 5.0.0-SNAPSHOT                               [2/27]
[INFO]   from core/foo-core/pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] Going to calculate checksum for project [groupId=com.example.foo, artifactId=foo-core]
[INFO] Scanning plugins configurations to find input files. Probing is enabled, values will be checked for presence in file system
[INFO] Found 421 input files. Project dir processing: 42, plugins: 6 millis
[INFO] Project inputs calculated in 77 ms. XX checksum [0a64c649f3c93a45] calculated in 151 ms.
[INFO] Attempting to restore project com.example.foo:foo-core from build cache
[INFO] Local build found by checksum 0a64c649f3c93a45
[INFO] Found cached build, restoring com.example.foo:foo-core from cache by checksum 0a64c649f3c93a45
[INFO] Project com.example.foo:foo-core restored partially. Highest cached goal: verify, requested: install
[INFO] Skipping plugin execution (cached): resources:resources
[INFO] Skipping plugin execution (cached): flatten:flatten
[INFO] Skipping plugin execution (cached): compiler:compile
[INFO] Skipping plugin execution (cached): resources:testResources
[INFO] Skipping plugin execution (cached): compiler:testCompile
[INFO] Skipping plugin execution (cached): surefire:test
[INFO] Skipping plugin execution (cached): jar:jar
[INFO] Skipping plugin execution (cached): source:jar-no-fork
[INFO]
[INFO] --- install:3.1.2:install (default-install) @ foo-core ---
[INFO] Installing /home/me/sources/foo-5.0.x/core/foo-core/pom.xml to /home/me/.m2/repository/com/example/foo/foo-core/5.0.0-SNAPSHOT/foo-core-5.0.0-SNAPSHOT.pom
[INFO] Installing /home/me/.m2/build-cache/v1/com.example.foo/foo-core/0a64c649f3c93a45/local/foo-core.jar to /home/me/.m2/repository/com/example/foo/foo-core/5.0.0-SNAPSHOT/foo-core-5.0.0-SNAPSHOT.jar
[INFO] Installing /home/me/.m2/build-cache/v1/com.example.foo/foo-core/0a64c649f3c93a45/local/foo-core-sources.jar to /home/me/.m2/repository/com/example/foo/foo-core/5.0.0-SNAPSHOT/foo-core-5.0.0-SNAPSHOT-sources.jar
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ foo-core ---
[INFO] Copying 1 resource from src/main/java/com/example/foo/core/spring/schema to target/classes/com/example/foo/core/spring/schema
[INFO] Copying 8 resources from src/main/resources to target/classes
[INFO]
[INFO] --- flatten:1.6.0:flatten (flatten) @ foo-core ---
[INFO] Generating flattened POM of project com.example.foo:foo-core:jar:5.0.0-SNAPSHOT...
[INFO]
[INFO] --- compiler:3.13.0:compile (default-compile) @ foo-core ---
[INFO] Recompiling the module because of changed source code.
[INFO] Compiling 354 source files with javac [debug deprecation target 17] to target/classes

此行为也不限于此示例;无论我传递给哪个 Maven 命令,我都会看到相同的行为:

test
package
verify
install
deploy

这是 Maven 构建缓存扩展支持的东西,还是我误解了它的用途?如果它确实支持这种用法,这是一个错误还是我做错了?作为参考,我使用 Java 17、Maven v3.9.6(通过 Maven Wrapper 脚本)、Maven Build Cache Extension v1.1.0 以及使用 Maven CI 友好版本构建的多模块项目。

maven
1个回答
0
投票

当扩展版本

1.2.0
发布时,这个问题应该得到解决。所以回答我的问题:

  1. 是的,这是 Maven Build Cache Extension 支持的。
  2. 是的,这是一个错误。

作为此答案的背景信息:为了自己调试问题,我克隆了源代码并在本地构建了扩展以添加一些日志记录以查看问题所在。令我惊讶的是,最新版本的源代码没有任何问题(

1.1.1-SNAPSHOT
)。我查看了版本
1.1.0
和最新提交之间的提交,发现 commit 5af2549,它修复了问题 MBUILDCACHE-80,并包含以下提交消息:

修复增量构建的目标高于最高缓存目标是从头开始重建整个项目

  • 修复增量构建缓存重放问题
  • 修复Issue67恢复错误的测试回归得到正确处理
  • 添加简单的 IncrementalRestoreTest 单元测试
  • 使用构建的最终工件名称修复恢复缓存的工件
  • 解决缓存恢复中
    restored
    变量使用的双重含义

报告的问题描述了我所观察到的错误:

当执行更高目标(即部署)然后当前最高缓存目标(即验证)的构建时,扩展会跳过缓存执行并在缓存目标和当前目标之间运行 mojos,同时缺少将缓存的最终工件恢复到项目构建目录中。之后,它从头开始再次运行完整构建,以重建工件并保存构建缓存。它不是通过重用已经打包的工件和执行来减少构建时间,而是几乎使重新运行部署以从头开始发布的时间增加了一倍。它还会导致 Maven 源插件 (3.3.0) 由于重复源工件错误而失败,从而导致部署构建失败。

© www.soinside.com 2019 - 2024. All rights reserved.