Better support for up-to-date checks about gwt-gradle-plugin HOT 6 OPEN

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.

from gwt-gradle-plugin.

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'

from gwt-gradle-plugin.

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)]  

from gwt-gradle-plugin.

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

from gwt-gradle-plugin.

+1 sounds like #77 is a duplicate of this

from gwt-gradle-plugin.

@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:

1. Are you using the Gradle Daemon?
2. 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?

from gwt-gradle-plugin.