[
https://issues.apache.org/jira/browse/MBUILDCACHE-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706667#comment-17706667
]
Tomáš Mrázek commented on MBUILDCACHE-45:
-----------------------------------------
You have to for some reason explicitly configure target subfolders.
{code:java}
<configuration>
<attachedOutputs>
<dirNames>
<dirName>classes</dirName>
<dirName>generated-sources</dirName>
<dirName>maven-status</dirName>
</dirNames>
</attachedOutputs>
</configuration> {code}
Then those subfolders are correctly zipped and stored and restored in cache.
I am on the other hand unable to restore the jar itself to target folder. Maybe
I just don't get the point of the extension.
Anyways I would expect, that input section would specify files to calculate
hash and defaults to include -> src, and output section would specify actual
files to cache and default to include -> target. Include cannot be specified
for the output tho. And attachedOutputs section is inherently defined for
target. Again I would expect this section to convey cacheable artefacts outside
of the target as some special cases. And I would expect, that all outputs would
be cached/zipped for every phase and then properly restored for the highest
phase run.
Attached outputs are always restored no matter the phase.
> Compiled classes are not copied/restored to target, causing higher phase
> builds to fail
> ---------------------------------------------------------------------------------------
>
> Key: MBUILDCACHE-45
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-45
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Environment: windows
> Reporter: Miguel Ortega
> Priority: Major
> Attachments: maven-cache.zip
>
>
> +*Step to reproduce*+
> 1. Execute a first command
> {code:java}
> mvn test{code}
> Results are cached (contrary to documentation that states that "cache will
> kick-in automatically on every lifecycle build of phase {{package}} or
> higher.") This could also be a feature since tests can be skipped if nothing
> changes.
> 2 . But if I run next:
> {code:java}
> mvn clean verify
> #OR
> mvn clean install{code}
> Then the build fails
> {code:java}
> [ERROR] Failed to execute goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage (repackage)
> on project demo: Execution repackage of goal
> org.springframework.boot:spring-boot-maven-plugin:3.0.2:repackage failed:
> Unable to find main class -> [Help 1]
> [ERROR]
> {code}
> The root cause seems to be that after "clean", the maven target directory is
> cleaned and even if the cache is detected, classes are not restored to the
> target folder anymore
> {code:java}
> [INFO] Attempting to restore project com.example:demo from build cache
> [INFO] Remote cache is incomplete or missing, trying local build for
> com.example:demo
> [INFO] Local build found by checksum 596f60b3f5056d7d
> [INFO] Found cached build, restoring com.example:demo from cache by checksum
> 596f60b3f5056d7d
> [INFO] Project com.example:demo restored partially. Highest cached goal:
> test, requested: install
> [INFO] Skipping plugin execution (cached): resources:resources
> [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 {code}
> *+Workaround+*
> Manually remove cache data or disable cache via command line argument
> *+Environment+*
> {code:java}
> Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
> Maven home: <REDACTED>
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime: <REDACTED>
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
