Gradle build compare fails - for an interesting reason

(Mark Petrovic) #1

I think this is a good question to post on the Gradle forums, as I’m probably not the only one who will run across this situation.

So I want to migrate from Gradle 1.3 to 1.4, and I’m using the ‘compare-gradle-builds’ plugin to assist me.

Here is my task config.

compareGradleBuilds {
    targetBuild.gradleVersion = "1.4"

Now it turns out that I have a subproject that implements a screenscraper based on the Geb Project. Geb is a browser automation tool implemented in Groovy. It’s working well for me.

When I execute the compareGradleBuild task, the compare fails in exactly the same way on a lot of classes that use Geb. Here is the failure explanation in the comparison report Gradle generates:

“entries are of identical size but have different content”

So I chose one class, GebConfig.class, and dissassembled the source and target versions with javap.

I send the disassembled versions to source.dis and target.dis, then I diff the files, hoping to find something interesting, as I have nothing else to go on. Here is what I see:

$ diff source.dis target.dis
< public static long __timeStamp__239_neverHappen1360272069931;
> public static long __timeStamp__239_neverHappen1360272209698;
  6: putstatic #129; //Field __timeStamp__239_neverHappen1360272069931:J
  6: putstatic #129; //Field __timeStamp__239_neverHappen1360272209698:J
  11: ldc2_w #130; //long 1360272069931l
  11: ldc2_w #130; //long 1360272209698l

So yes, the source and target class files are different, but they are not different in a way that I care about for build comparison purposes.

I guess my question is: what’s putting the timestamp in these class files? Groovy or Geb or neither?


(Peter Niederwieser) #2

It’s an unfortunate behavior of the Groovy compiler that causes lots of headaches (not only for Gradle).