[MBUILDCACHE-116] Extension fails to regenerate all files in target directory

[jira-importer]

Gili opened MBUILDCACHE-116 and commented

1. Create a project with dependencies that contains:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
        <execution>
            <id>copy-dependencies</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>copy-dependencies</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.directory}/lib</outputDirectory>
                <overWriteReleases>false</overWriteReleases>
                <overWriteSnapshots>false</overWriteSnapshots>
                <overWriteIfNewer>true</overWriteIfNewer>
                <useBaseVersion>false</useBaseVersion>
                <includeScope>runtime</includeScope>
            </configuration>
        </execution>
    </executions>
</plugin>

2. Run "mvn verify".
3. Notice that the "target" directory contains the main JAR file and "target/lib" contains the JAR file's dependencies
4. Delete the target directory
5. Run "mvn verify" again.
6. Notice that "target" directory contains the main JAR file but the "target/lib" directory is missing.

{}Expected behavior{}: "mvn verify" should always generate the same output.

This might be a regression of https://issues.apache.org/jira/browse/MBUILDCACHE-67. Per https://stackoverflow.com/q/78057064/14731 this issue existed back in version 1.0.1, was fixed by version 1.1.0, but it seems to be back now.

Can someone please take a look at this?

---

Affects: 1.2.0

[jira-importer]

Sebastian Tiemann commented

Hey,
I had a look at what you described and tested against versions 1.2.0 and 1.1.0 with your dependecy-plugin configuration in a small project.

In both versions, I could observe what you mentioned and I see no bug here.

This is the current default behaviour. The JAR file is moved to a cache entry and restored to the target-directory if you run "mvn verify" again.

To achieve the restoration of other files and directories, you should add a configuration file for the build cache extension, depending on your needs.

For details, have a look at the documentation, paragraph "Adding build cache config".

This snippet, for example, will make sure, that the whole target/ is cached (and restored):

 

<cache xmlns="http://maven.apache.org/BUILD-CACHE-CONFIG/1.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://maven.apache.org/BUILD-CACHE-CONFIG/1.2.0 https://maven.apache.org/xsd/build-cache-config-1.2.0.xsd">
    <configuration>
        <attachedOutputs>
            <dirNames>
                <dirName glob='*' />
            </dirNames>
        </attachedOutputs>
    </configuration>
</cache>

 

[jira-importer]

Gili commented

Hi Sebastian,

Thank you for your reply.

I am happy to hear that this is just a configuration problem on my end.

Is there any chance of improving the documentation to warn about this situation, and/or having maven-build-cache-extension log a warning if it finds unexpected files/directories in the target directory that are not being cached? It might prevent future users a lot of grief. Thank you.

PS: it's a bit weird to have a single configuration for a multi-project setup, especially with regard to {}attachedOutputs{}. Is there a way to specify a root configuration file and override it in a per-project basis?

[cowwoc]

PR #387 fixes a related restoration issue: timestamp preservation when extracting cached files.

While this issue (#269) is about missing files not being restored, PR #387 addresses the problem of files being restored with incorrect timestamps, which caused Maven warnings like:

[WARNING] File is more recent than the packaged artifact, please run a full 'mvn package' build

Both issues involve improving the reliability and correctness of cache restoration. The timestamp fix ensures that restored files have the same modification times as when they were cached.