Behavior when applying via plugins block and "apply plugin" are different

[markelliot]

When applied through the plugins closure on a top level project, the processors jar is not added to Eclipse classpath. In the same project, if applied through apply plugin, the processors jar is added to the Eclipse classpath. I expect the latter behavior.

[alicederyn]

That's really weird. Can you give me more details about your setup — Gradle version, Eclipse version, plugin version? (Ideally attach a repro zip, if you have time.)

[markelliot]

Tried with:

• Gradle 2.6 and 2.7
• Eclipse Mars
• Processors 1.1

In case it matters, I was trying to use org.immutables:value:2.0.21.

The failing setup looked like:

plugins {
   id 'eclipse'
   id 'java'
   id 'org.inferred.processors' version '1.1'
}

group 'group'

repositories {
    jcenter()
}

dependencies {
    processor 'org.immutables:value:2.0.21'
}

And the working setup like:

buildscript {
  repositories {
    maven {
      url 'https://plugins.gradle.org/m2/'
    }
  }
  dependencies {
    classpath 'gradle.plugin.org.inferred:gradle-processors:1.1'
  }
}

apply plugin: 'java'
apply plugin: 'eclipse'
apply plugin: 'org.inferred.processors'

group 'group'

repositories {
    jcenter()
}

dependencies {
    processor 'org.immutables:value:2.0.21'
}

[alicederyn]

Could you post the output of

cat gradle/wrapper/gradle-wrapper.properties

(Sorry, just want to double-check there are no weird modified Gradles being pulled in somehow.)

[markelliot]

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.7-bin.zip

[markelliot]

Ok, I think I found it; apparently the order in plugins matters:

fails to fix classpath:

plugins {
    id 'eclipse'
    id 'java'
    id 'org.inferred.processors' version '1.1'
}

correct classpath:

plugins {
    id 'java'
    id 'eclipse'
    id 'org.inferred.processors' version '1.1'
}

[alicederyn]

O.o omg

[markelliot]

Yeah, worse yet, if I mutate the working version to swap eclipse for baseline, things fail again (baseline-eclipse applies the eclipse plugin):

plugins {
    id 'java'
    id 'com.palantir.baseline-eclipse' version '0.1.1'
    id 'org.inferred.processors' version '1.1'
}

...but I'll follow up with @uschi2000 about that.

Anyway, short of filing a Gradle bug I don't think there's things to be done here.

[alicederyn]

I'll leave this open and check there's nothing going wrong in the plugin. Thanks for figuring this out!

[punya]

Booooo Gradle.... I thought the whole point of the "declarative" plugins syntax was to obviate such considerations :(

[alicederyn]

We may be doing something dodgy in the gradle-processors plugin, though.

[uschi2000]

In the plugins{} syntax, when is Plugin#apply expected to run? I don't think order independence can work once plugins extend behaviour of others.

[alicederyn]

We take the approach of installing a task that runs after the java/eclipse/etc plugin runs. It may be there is an ordering issue happening there, I suppose.

[alicederyn]

Sorry it's taken me so long to address this. I was bamboozled by being apparently unable to replicate it with apply plugin, which is necessary for testing. It turns out the order plugins are applied with the plugins {} syntax is non-trivial. The example given was:

plugins {
  id 'eclipse'
  id 'java'
  id 'org.inferred.processors' version '1.1'
}

This appears to be equivalent to:

apply plugin: 'org.inferred.processors'
apply plugin: 'eclipse'
apply plugin: 'java'

or possibly:

apply plugin: 'eclipse'
apply plugin: 'org.inferred.processors'
apply plugin: 'java'

Weird.

[jmcampanini]

could the ordering issues be avoided if we just do the work in an project.afterEvaluate block?

[alicederyn]

Sadly, no, we need to do the work before the project is evaluated. I have a PR in review that fixes the issue, though.

[alicederyn]

This is fixed in v1.2.3. Sorry for the delay, everyone!