Jar task is UP_TO_DATE altough manifest attribute was changed

Old Forum Archive Bugs
,
1

I also asked this on stackoverflow:

I put this into my build.gradle file:

jar.manifest.attributes ‘Main-Class’: ‘de.gradlebuch.HelloWorld’

After that, the build output should look like this:

PS C:\Users\user\Desktop\gradle test\HelloWorld> gradle build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build UP-TO-DATE

Unfortunately, it isn’t. I get:

PS C:\Users\user\Desktop\gradle test\HelloWorld> gradle build
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build UP-TO-DATE

The jar and assembler task are UP_TO_DATE and the attribute is not in the Manifest.MF file.

When I do

gradle clean
gradle build

everything is fine. But I tought Gradle would be capable of detecting these kind of changes without rebuilding everyting.

What can I do to get Gradle detect changes in my build.gradle file?

2

I’m surprised this isn’t working. In fact, several user have complained about the opposite: they would like Gradle to ignore changes to Manifest attributes and not rebuild the jar file.

If you run the build with --info you’ll see messages about why Gradle considers each task to be up-to-date. Is it possible that your jar file contains no sources?

3

The jar file contains a HelloWorld class and a Hello World Junit test. Both are working (The jar prints hello world if I run “gradle clean” before the build and the test fails the build if i change it).

The info logs say:
Skipping task ‘:classes’ as it has no actions.
:classes UP-TO-DATE
:classes (Thread[main,5,main]) completed. Took 0.015 secs.
:jar (Thread[main,5,main]) started.
:jar
Skipping task ‘:jar’ as it is up-to-date (took 0.016 secs).
:jar UP-TO-DATE
:jar (Thread[main,5,main]) completed. Took 0.016 secs.
:assemble (Thread[main,5,main]) started.
:assemble
Skipping task ‘:assemble’ as it has no actions.
:assemble UP-TO-DATE
:assemble (Thread[main,5,main]) completed. Took 0.016 secs.
:compileTestJava (Thread[main,5,main]) started.
:compileTestJava
Skipping task ‘:compileTestJava’ as it is up-to-date (took 0.234 secs).

I am using windows 8.1 and gradle 2.7
The project can be found here: https://176.28.13.141/owncloud/index.php/s/GoMTGukw1g42Zfq

4

Thanks Felix. I’ve confirmed this bug: it looks like a regression was introduced in Gradle 2.5.

I’ve raised GRADLE-3340 to track this. Thanks for the report.

5

Same issue here. We’re building a tar.gz providing an executable jar with its 3rd party dependencies in a subfolder. The MANIFEST.MF inside the JAR contains the classpath with all these libraries from runtime dependency. Changing only a 3rd dependency, i.e. by upgrading its version results in a UP-TO-DATE JAR-Task.