How to allow running plugin in a Linux Container build with source mounted from Windows

[slominskir]

After upgrading to the latest version from a very old version I'm now running into a build problem. I've got the plugin working in a Gradle project in the simple general case, but when I attempt to use the plugin inside a Docker build on Windows with a Linux Container it fails. The Docker build includes the current working directory (source files) as build context.

I was already working around line endings, which I corrected via .gitattributes (I'm using git), to ensure the files are always LF (even on Windows). However, the plugin now appears to get confused with paths during the spotlessJava task and mixes both UNIX and Windows paths. The Docker build that executes the Gradle build using the spotless plugin generates the following error, which indicates the paths detected by the plugin are a mix of both Container Linux and Host Windows:

#12 17.75 FAILURE: Build failed with an exception.
#12 17.75
#12 17.75 * What went wrong:
#12 17.75 Execution failed for task ':spotlessJava'.
#12 17.75 > Spotless error! All target files must be within the project dir.
#12 17.75     project dir: /app
#12 17.75          target: /home/gradle/.gradle/daemon/9.0.0/C:\Users\slominskir\IdeaProjects\myproject\src\main\java\org\myorg\myproject\Application.java

Using spotless plugin in a container build was working before with plugin version 6.25.0 and Gradle 7 (and Java 17). Upgrading to plugin version 7.2.1 and Gradle 9 (and Java 21) and I'm now seeing this issue.

I am using barebones config / defaults. The build.gradle includes:

plugins {
    id 'war'
    id 'com.diffplug.spotless' version '7.2.1'
}

spotless {
    java {
        googleJavaFormat()
    }
}

Ideas? Do I need to override some default path setting maybe?

[nedtwigg]

• My guess is that there's a target call inside a spotless block somewhere.
• I might try binary-searching through the Spotless changelog to find the exact point where yours failed. Maybe start by trying the least 6.x and then the first 7.0. We add migration notes (sometimes retroactively) when a release requires anyone to change something about their scripts.