do not try to compile java files if we don't generate any

[martinbonnin]

Should fix #1352

[digitalbuddha]

Is there a way to write a test for this? Maybe a module within repo with this setup

[martinbonnin]

Test project added there: https://github.com/apollographql/apollo-android/blob/95b0e854eb5953d95acceabb474a8e193b9af3f3/apollo-gradle-plugin/src/test/testProject/kotlin/build.gradle

As it's using the snapshots, it will fail until new snapshosts are deployed. I'm not sure how this is handled for other plugin tests ?

[sav007]

Do you know why integration test fails on CI? As it a composite test and should run with the latest changes to plugin without waiting for snapshot to be published.

[martinbonnin]

Pretty sure I didn't do the composite thing. Right now it uses the snapshot plugin which is why it fails. I'll look into composite tests

[martinbonnin]

It should be good. 2 points worth noting:

• I had to move the creation of the apollo tasks to afterEvaluate. This might or might not have side effects but it's the only way I found to know reliably the value of apollo.generateKotlinModels and configure the java task.
• The other tests simply add the apollo-api code to the java sourceSet which defeats the value of this test (testing that the project compiles without any java file). In order to still have the api dependency, I included the snapshot so the test will run with a local apollo-plugin and a snapshot apollo-api. This might or might not be an issue...

[sav007]

I will take a look on my sample project with snapshot version if afterEvaluate caused any issues, it shouldn't but will check.

[alexxxdev]

I will take a look on my sample project with snapshot version if afterEvaluate caused any issues, it shouldn't but will check.

@sav007 @martijnwalraven it seems
now it causes problems with compile%name%Kotlin
for any value of generateKotlinModels
project is 100% kotlin

/build/apollo-codegen/ empty & /build/generated/source/apollo doesn't exist

[AllanWang]

^ For me the generated sources actually do exist, but they don't get resolved properly; gradle won't allow me to use it.

#1372