JarBuilder still runs the bnd Builder even though it is up to date

[mbelling]

We have a large subproject of our build that applies the gradle-bundle-plugin. We found that the plugin will run the aQute.bnd.osgi.Builder, and in the end mark the task as up to date. Being a large subproject with a large amount of classes, this eats up over a minute of build time for an 'up-to-date' task. I think the up to date check should prevent the Builder from being run, to save on build time.

Edit: This was with Gradle 2.14, but I tested with Gradle 4.2-rc-2 as well, so the gradle version does not seem to have an effect.

[mbelling]

A clipping of a Gradle 2.14 debug log if it helps, with some things taken our for brevity.

09:28:30.229 [LIFECYCLE] [class org.gradle.TaskExecutionLogger] :someProject:jar
09:28:30.229 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Starting to execute task ':someProject:jar'
09:28:30.229 [DEBUG] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Determining if task ':someProject:jar' is up-to-date
09:28:30.245 [DEBUG] [org.gradle.api.internal.changedetection.state.CachingTreeVisitor] Cache hit directory 'C:\someProject\build\classes\main'
09:28:30.245 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting base C:\someProject
09:28:30.245 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting properties { ... stuff ... }
...
09:28:30.276 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting classpath ...classpath...
09:28:30.276 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting source path C:\someProject\src\main\java
09:28:30.955 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting resources C:\someProject\build\classes\main
09:28:30.956 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting version 1.0.0.SNAPSHOT
09:28:30.956 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting name someProject
09:28:30.956 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting trace false
09:28:30.956 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] Setting fail on error false
09:28:31.369 [DEBUG] [org.dm.gradle.plugins.bundle.JarBuilder] The Builder is about to generate a jar using classpath: [... classpath ...]
09:28:31.369 [DEBUG] [aQute.bnd.osgi.Builder] build
... 106 seconds of Builder spam ...
09:30:17.145 [INFO] [org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter] Skipping task ':someProject:jar' as it is up-to-date (took 1 mins 46.916 secs).
09:30:17.145 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':someProject:jar'
09:30:17.145 [LIFECYCLE] [class org.gradle.TaskExecutionLogger] :someProject:jar UP-TO-DATE

[mbelling]

I think this might have to do with the manifest being generated. From a clean state, it seems to run the JarBuilder.build method once while generating the manifest in the writeManifestTo method, and again while generating the jar in the writeJarTo method.

void writeManifestTo(OutputStream outputStream, @Nullable Closure c) {
    def builder = build()

    def manifest = builder.jar.manifest.clone() as Manifest
    if (c != null) {
        c manifest
    }
    try {
        Jar.writeManifest manifest, outputStream
    } finally {
        outputStream.close()
        closeBuilder(builder)
    }
}

void writeJarTo(File output) {
    def builder = null
    try {
        builder = build()

        output.getParentFile().mkdirs()
        builder.jar.write output
    } finally {
        closeBuilder(builder)
    }
}

So the issue on a repeated build I assume has to do with the manifest generation calling the build method. Is that avoidable on an up-to-date build?

[mbelling]

With further digging I realize that the builder is run to generate the manifest to determine if it is up to date. Getting around this might be tricky.