[MBUILDCACHE-45] Compiled classes are not copied/restored to target, causing higher phase builds to fail

[jira-importer]

Miguel Ortega opened MBUILDCACHE-45 and commented

+Step to reproduce+

1. Execute a first command on a pristine projet( NO CACHE has ever been stored)

mvn test

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: 

mvn clean verify
#OR
mvn clean install

Then the build fails

[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]
 

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

[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 

+Workaround+

Manually remove cache data or disable cache via command line argument

+Environment+

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"

---

Attachments:

• maven-cache.zip (5.05 kB)

2 votes, 8 watchers

[jira-importer]

Tomáš Mrázek commented

 

You have to for some reason explicitly configure target subfolders.

<configuration>
    <attachedOutputs>
        <dirNames>
            <dirName>classes</dirName>
            <dirName>generated-sources</dirName>
            <dirName>maven-status</dirName>
        </dirNames>
    </attachedOutputs>
</configuration> 

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.

 

[jira-importer]

Olivier Lamy commented

strange because I use this on very large project without any issue.
Do you have an example to reproduce?
Because I really suspect it is because of spring-boot-maven-plugin and so you need extra configuration.

[jira-importer]

Miguel Ortega commented

Olivier Lamy Hello Olivier, in the ticket I attached an example to reproduce, which is indeed a very simple spring boot project, where I can reproduce what I described in the ticket. 

It seems in a pristine project the cache will not cache "target/classes" files if I do "mvn clean compile" which seems coherent with the documentation stating "Once the extension is activated, the cache automatically kicks in on every package or higher phase."

But then again it you do a "mvn clean compile" (where cache does not exists) and an the "mvn clean package" you get an error as described above, which does not seem nominal behaviour. Hopefully i'm not missing something obvious. 

[jira-importer]

Maximilian Novikov commented

spring-boot-maven-plugin tries to attach artifacts from 'target' folder instead of using the actual data from maven model where artifacts are pointed to cached data... i'd say it should be fixed in spring-boot-maven-plugin

[jira-importer]

Réda Housni Alaoui commented

I have the same issue with the sonar-maven-plugin. The latter expects .class files in target folders.