Gradle plugin does not allow Eclipse configuration file from web?

[tiberiuvs]

I don't think this is a bug, I'm just unclear about the expected behavior here.

I'm using the gradle plugin with an eclipse configuration file. I would like this file to exist somewhere an external GitHub repo, and not in the project itself. If I'm understanding it right, I should be able to specify file by URL in some way.

I currently have this setup, where the input is a File.

java {
        target '*/src/*/java/**/*.java'
        removeUnusedImports()
        def fileLocation = 'https:////github....xml'
        eclipse('4.16.0').configFile resources.text.fromUri(fileLocation).asFile()
    }

I do see this error message:

> Task :spotlessJava FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':spotlessJava'.
> File signature can only be created for existing regular files, given: /Users/.../build/tmp/resource/wrappedInternalText8119286753158356024.txt

It looks like the check at

spotless/lib/src/main/java/com/diffplug/spotless/FileSignature.java

Line 131 in b77fef2

"File signature can only be created for existing regular files, given: "

is failing here, but from what I'm understanding, Gradle is actually downloading the content into a file.

Can you help me identify what I'm missing here? Much appreciated.

[nedtwigg]

You are correct that configFile expects a file, and also that .fromUri(fileLocation).asFile() ought to fix this. Based on the fact that it is failing, my guess is that one of the following is true:

• Gradle is deleting the file before Spotless gets it
• Gradle returns the file, but doesn't create it until some later time, too late for Spotless

My recommendation for a case like this is to use blowdryer. If the URL you are downloading is guaranteed to be immutable (because it's a link to either a tag or a specific commit), then blowdryer will be a lot faster. Even if you don't use the whole plugin, you can still use the static File 干.immutableUrl(String guaranteedImmutableUrl) method to fix this problem, and speed things up.

[laffer1]

If you don't want to add an extra plugin dependency, you can simply fetch the file like so:

def f = new File('the file path')
if (!f.exists()) {
    new URL('the url').withInputStream{ i -> f.withOutputStream{ it << i }}
}

[nedtwigg]

The advantage of blowdryer is that it will be downloaded once ever, and your builds will be faster and even offline-capable from then on.

[lyharrietbui]

@nedtwigg Hi Ned, I ran into similar issue when configuring diktat. Is it possible to configure a FileSignature to resolve at Spotless task run-time; this deferred resolution works for executables.

[nedtwigg]

FileSignature has to resolve a configure-time, because it's needed for up-to-date calculation.

[luisalves00]

@nedtwigg can't you make it as a closure? The idea is to run at the configure phase and later after clean again. So far I can only run it if I do ./gradlew clean && ./gradlew build as if I do together the clean removes the expanded file after configure phase.

[nedtwigg]

Feel free to submit a PR, if it doesn't break anything else I'd be happy to merge it.

As an aside, I think you're targeting a strange usecase. You don't trust build, so you want to run clean first. That's fair enough, build has a bunch of machinery to make incremental builds fast, maybe there's bugs there, safer to always start from zero. But, you want gradle clean build to work, and gradle clean && gradle build is unacceptable to you. I would expect gradle clean build to be the most bug-producing command you could possibly ask for from a build system. You're telling Gradle "take the DAG whose purpose is to facilitate up-to-date checks and fast incremental builds, and use it to sequence one set of tasks that nuke all the up-to-date checks alongside an unrelated set of tasks that rely on those up-to-date tasks".

[luisalves00]

Doubt will have the time to look at the code and try to do a PR. Anyway clean is not mandatory and we don't even most of the times need to do it, but it's part of gradle lifecycle and when is executed together it fails, which is confusing for developers.