`artifactoryDeploy` uses old artifact information

Describe the bug After changing the version of my artifact, the artifactoyDeploy task attempts to deploy to Artifactory using outdated build info.

This appears to be caused by bad caching introduced in #301. That PR introduced a new task called extractModuleInfo, which declares its output but not its input. That causes it to be considered up-to-date if the moduleInfo.json file has not changed, even if the input values have changed. So although the artifactoryPublish task correctly declares all of its inputs, the module information still ends up being outdated.

To Reproduce Using this build.gradle file:

plugins {
    id 'java'
    id 'maven-publish'
    id 'com.jfrog.artifactory' version '4.17.2'
}

task("writeSources") {
    doLast {
        file("src/main/java").mkdirs()
        file("src/main/java/TestClass.java").write("class TestClass { }")
    }
}

version = System.getenv("VERSION")
repositories { jcenter() }
tasks.compileJava { dependsOn(writeSources) }

publishing.publications.create("mavenJava", MavenPublication) {
    artifact tasks["jar"]
}

artifactory {
    publish {
        defaults {
            publications "mavenJava"
        }
    }
}

1. VERSION=1.2.3 ./gradlew jar extractModuleInfo
2. cat build/moduleInfo.json -> "id" : ":art:1.2.3"
3. VERSION=7.8.9 ./gradlew jar extractModuleInfo
4. cat build/moduleInfo.json -> "id" : ":art:1.2.3"

The moduleInfo.json file was not updated with the new version information. Note that this caching bug also affects the build-info.json file, but that is harder to demonstrate without actually performing the publish to a real Artifactory instance.

Expected behavior The publish should only use the current module info, not module info that was collected in previous builds.

Versions

• Gradle Artifactory plugin version: 4.17.2
• Operating system: macOS Mojave (10.14.5)
• Artifactory Version: 7.4.3

[ghale]

It probably makes sense to just leave this task always out-of-date for now. The input for this task is the Module object, which isn’t a Gradle-specific object, so adding nested annotations wouldn’t make sense. We’d need to interrogate the Module model and then produce something that could be hashed as an input, which is basically what the json serialization does, so the only work we would save by making it up-to-date is the write itself.

Stepping back, the whole point of this task is to share the Module info across projects in a parallel-safe way that is compatible with older versions of Gradle. This is one of the use cases that build services are designed to solve, but these are only available in Gradle 6+. Perhaps once support is dropped for older versions of Gradle we could just migrate this functionality to a build service and get rid of these tasks altogether. For now, maybe we just leave these tasks non-incremental.

[davidnelson-hms]

One of Gradle’s fundamental value propositions is incremental build. It’s literally the first bullet point in the user guide article “What is Gradle?”. Needing to run clean in order for the build output to be correct violates this fundamental principle. Moreover, if clean for some reason is necessary to ensure correct behavior, it should be forced; as it stands the build can silently use the wrong version, which is a very serious bug that needs to be mitigated somehow

If a task cannot accurately predict what its inputs and outputs are, then the correct thing for it to do is to not declare any outputs. That way, it will never be cached, and will always run so it is up-to-date. Doing that might solve the current problem with extractModuleInfo.

However, as I said in the issue description, I don’t think it is the case that this task cannot be cached correctly, because the artifactoryPublish task (which was essentially doing the same work as extractModuleInfo prior to #301) declares its inputs and outputs correctly, and does not suffer from the same caching bug. Only when we update our plugin version past 4.13.0, where extractModuleInfo was introduced, do we experience this bug.