Gradle checks 3rd Party method calls preventing a project not being UP-TO-DATE?


(Carlo Luib-Finetti) #1

I notice some strange behaviour (at least for me) when I do a compile on a project which uses ActiveMQ as a dependency. This is an example of the output messages:

C:\Users\cluib\.gradle\caches\modules-2\files-2.1\org.apache.activemq\activemq-all.9.013b37f5ea86f6ba7e01af3d01ad97b
34fca8883\activemq-all-5.9.0.jar(org/apache/log4j/helpers/Loader.java):166: warning: non-varargs call of varargs method
with inexact argument type for last parameter;
    return (ClassLoader) method.invoke(Thread.currentThread(), null);
                                                               ^
  cast to Object for a varargs call
  cast to Object[] for a non-varargs call and to suppress this warning
Note: C:\Users\cluib\.gradle\caches\modules-2\files-2.1\org.apache.activemq\activemq-all.9.013b37f5ea86f6ba7e01af3d0
1ad97b34fca8883\activemq-all-5.9.0.jar(org/apache/log4j/spi/NOPLogger.java) uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
5 warnings

Warnings like these seem to prevent Gradle seeing a project as UP-TO_DATE, so it will always be compiled.

Is this a correct behaviour? And if, can this be overriden somehow?

(BTW: I’m using Gradle 1.11)


(Carlo Luib-Finetti) #2

Okay, I think I mixed to different things together above. As part of jar building I’m creating a build-info file and put it into the jar. Because I made the jar task dependent on this build-info file creation, the jar is never up to date.

So my question is reduced to: why are there warnings and can I suppress them?


(Peter Niederwieser) #3

These are javac warnings. Check the javac docs for the javac option(s) to suppress them. Then you can configure the ‘JavaCompile’ tasks accordingly. (See the Gradle Build Language Reference for details on the latter.)


(Carlo Luib-Finetti) #4

yeah, sorry, I was completely misguided by these warnings and my suspicion that these were the culprits when I noticed that repeatedly calling the jar task did not result in UP-TO-DATE.

In fact, the declaration of “jar” with a “dependsOn” task that creates the build-info was the cause that jars were never UP-TO-DATE.

I removed the dependsOn-clause and just called the create task. This task is guarded by

onlyIf
{
 ! outputs.upToDateWhen {
        ...

This seems to work now.


(Carlo Luib-Finetti) #5

No, it doesn’t. After playing around I’ve found, that it isn’t easy to figure out if anything changed and was not UP-TO-DATE. I finally found this discussion http://forums.gradle.org/gradle/topics/dynamic_manifest_mf_attribute_new_date_causes_gradle_to_build_the_jar_every_time_even_though_nothing_else_changed, using the buildDate-variable, which will only be set in compileJava or processResources. Then, on jar.doLast, this will be checked and only if set a new buildInfo will be created.