steffenschaefer
Better support for up-to-date checks
Setup
Gradle 1.10 Plugin 0.3 OS Windows 7
Scenario
Running gradle assemble multiple times in a row without changing any of the files.
Expected
The gwt tasks are executed on the first run but on the following runs the gwt tasks are skipped as UP-TO-DATE.
Observed
The gwt tasks are executed on each and every run although no source files have been changed. This is very tiring considering that the compileGwt task might take quite some time to generate the javascript.
up-to-date checks of compileGwt work for me. On the second run it's correctly marked as UP-TO-DATE. I tested it using one of the example projects and a real world project. The output of the example project's build:
[sts] -----------------------------------------------------
[sts] Starting Gradle build for the following tasks:
[sts] :example-simple-war:assemble
[sts] -----------------------------------------------------
The TaskContainer.add() method has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the create() method instead.
:example-simple-war:compileJava UP-TO-DATE
:example-simple-war:processResources UP-TO-DATE
:example-simple-war:classes UP-TO-DATE
:example-simple-war:compileGwt UP-TO-DATE
:example-simple-war:war UP-TO-DATE
:example-simple-war:assemble UP-TO-DATE
BUILD SUCCESSFUL
Total time: 2.25 secs
[sts] -----------------------------------------------------
[sts] Build finished succesfully!
[sts] Time taken: 0 min, 2 sec
[sts] -----------------------------------------------------
So I guess it is related to your specific build. Be aware that not only the source files are relevant for the up-to-date check but also the compiler flags that possibly change the output (e.g. turning closure compiler on/off).
As far as I remember appending "-i" (sets the log level to info) to the gradle command line will show why the task isn't considered up-to-date.
I'll leave this issue open to wait for feedback. Possibly it's an issue that only occurs in a specific configuration.
OK, I tested it some more.
The up-to-date check works fine but when I add style = 'DETAILED' the check is broken in our build. I can't get this reproduced in the the example project simple-war.
Output from gradle :compileGwt -i in our build is always although the style never changes:
Executing task ':compileGwt' (up-to-date check took 0.069 secs) due to:
Value of input property 'style' has changed for task ':compileGwt'
This seems to be a class loader problem or alike. After debugging gradle I can see that the current style value, when compared with the value from the previous run, is in fact two different instances of the same enum value.
object1 Style (id=7033)
'object1' referenced from:
name "OBF" (id=217)
ordinal 0 [0x0] [^@ (NUL)]
object2 Style (id=6977)
'object2' referenced from:
name "OBF" (id=217)
ordinal 0 [0x0] [^@ (NUL)]
The track at gradle.org ...
http://forums.gradle.org/gradle/topics/two_different_instances_of_the_same_enum_value_for_previous_and_current_input_property_when_using_the_gradle_daemon?utm_content=topic_link&utm_medium=email&utm_source=new_topic
http://issues.gradle.org/browse/GRADLE-3018
@rbaradari I'm investigating Gradle's handling of UP-TO-DATE checking when using enum properties as @Inputs. Indeed what's happening is that Gradle creates a new ClassLoader under certain circumstances (for example, if the build.gradle is changed) and since we're comparing instances of Style etc. from different ClassLoaders, they're not equal.
However, I'm having trouble reproducing the specific behavior you're seeing. I have created an example GWT project in the hopes of replicating this exact behavior.
It would be especially helpful if you could answer 2 things for me:
- Are you using the Gradle Daemon?
- Do you have any example project that you can share that exhibits the behavior you describe in this issue? If not, can you tell me what types of changes you're making and what Gradle tasks you're executing?
