palantir/gradle-processors

Gradle plugin for integrating Java annotation processors

Gradle Processors

A plugin for Gradle that cleans up integration of Java annotation processors with the Eclipse and IDEA plugins.

Quickstart

To use it, add the following to your projects' build.gradle file:

plugins {
  id 'org.inferred.processors' version '<LATEST VERSION>'
}

The eclipse and idea tasks will now configure your IDE to run annotation processors as part of their regular compilation when you use an annotationProcessor dependency.

dependencies {
  annotationProcessor 'com.google.dagger:dagger-compiler:2.8'
  implementation 'com.google.dagger:dagger:2.8'
}

Gradle 4.5 and earlier

If you are still using Gradle 4.5 or earlier, you can use the legacy processor dependency type to enable annotation processing:

dependencies {
  processor 'com.google.auto.value:auto-value:1.0'
}

This functions as a combination of the modern "annotationProcessor" and "compileOnly" blocks: it both enables the annotation processor, and makes any annotations it exposes available to use in source code.

Gradle 2.0 and earlier

For users of Gradle 2.0 and earlier, the plugins API is not available. Instead, add the following to your top-level build.gradle file:

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

And just the apply directive to your subproject build.gradle files:

apply plugin: 'org.inferred.processors'

You can now include annotation processors with the processor dependency type, as above.

Building from source

To build the project from source, run ./gradlew build, or gradlew.bat build on Windows, in the root directory of your checkout. You will need Java installed.

License

Copyright 2015 Palantir Technologies, Inc. All rights reserved.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

gradle-processors's Issues

Immutables processor writes to generated_src and is not clean friendly

What happened?

IntelliJ IDEA 2020.3.1 (Ultimate Edition)
Build #IU-203.6682.168, built on December 29, 2020

Running ./gradlew idea generates Immutables annotated files under "${projectDir}/generated_src/. These generated_src files are not cleaned when running ./gradlew clean as expected. I imagine there is a reason this plugin does not write to `"${buildDir}" by default.

What did you want to happen?

If a Gradle plugin generates code it should have an equivalent clean command.

Could not get unknown property 'idea' for root project

Hi,

I cannot make this plugin work on my project, i always get the same error during build :
Could not get unknown property 'idea' for root project

Any thoughts ?

Does work in IntelliJ

To get it to work, I have to first:

1. Go to Build, Execution, Deployment > Compiler > Annotation Processors
    Settings should be: Enable annotation processing

2. Module Content Root, change production -> generated_src and test -> generated_testSrc

FindBugs GeneratedClassesJar task issues when run in parallel with the test task

Running into a strange issue issue on versions of gradle-processors since v1.2.10 when the FindBugs GeneratedClassesJar task runs in parallel with the Gradle test task. Not sure if there's anything this plugin can reasonably do, but writing up in case there are any thoughts or ideas. Summarizing this in general terms since this is public Github, but happy to provide more details separately.

We basically have a standard internal service setup with "my-service-api" and "my-service-server" projects. "my-service-api" includes some classes generated through the immutables library which are used by "my-service-server". In more recent versions of the gradle-processors library, we see that our build fails with the JVM crash described in https://blogs.oracle.com/poonam/crashes-in-zipgetentry, which apparently happens when "a jar file being accessed has been modified/overwritten while the JVM instance was running."

From binary-searching versions, we're seeing that this happens starting in v1.2.10, due to the changes in the commit fb5d2f3 that adds the FindBugs GeneratedClassesJar task. The above crash seems to happen when the FindBugs GeneratedClasesJar runs in parallel with the unit tests for the server project. My guess is that it's the generated Java files from the immutables classes that are specifically hitting the above issue.

The workaround that we're successfully using for now is to require the FindBugs GeneratedClassesJar task to run after the tests, e.g. by including gradle statements such as:

tasks.getByPath("my-service-api:findbugsMainGeneratedClassesJar").mustRunAfter(":my-service-server:test")
tasks.getByPath(":my-service-api:findbugsTestGeneratedClassesJar").mustRunAfter(":my-service-server:test")

The direct causes seem to be the JVM bug listed above (and fixed in Java 9 in https://bugs.openjdk.java.net/browse/JDK-8142508) and the fragility of JVM class loading, but curious if there's anything that could be done to further defend against this (e.g. by sandboxing somehow).

Specify process order

I have 2 annotation processors, 1 needs to be executed before the other.

How would you be able to perform this task with the plugin?

License incorrect

You've not filled out the boilerplate in the license.

generated_src directory isn't marked correctly in IntelliJ

In version 1.2.1 with Gradle 2.12 the generated_src directory doesn't get marked as a source root in IntelliJ. It seems to work fine if I just change my version for org.inferred.processors to 1.1.6.

Incorrect output directory for eclipse projects on Windows for 1.2.12

• On unix machines, this project generates eclipse projects whose output source is generated/java
• On windows machines, the output source is instead just generatedjava, but the plugin itself puts the code in generated/java, so there are two copies of the output source.

The cause is that the .settings/org.eclipse.jdt.apt.core.prefs has the following error:

org.eclipse.jdt.apt.genSrcDir=generated\java   <-- what it does have
org.eclipse.jdt.apt.genSrcDir=generated\\java  <-- what it should have

One fix is to escape the argument when it is passed, and the other is to fix it in the template engine.

Easiest thing is to escape the argument with a simple .replace("\\", "\\\\").

processor transitive dependencies get added to the project as provided for IntelliJ

As the title says. This wouldn't be a problem except it overrides "compile" dependencies by switching them to provided. They then can't be found when running the application through intelliJ

Processors 2.0.0 do not work well with immutables

To upgrade gradle-processors to 2.0.0 I had to add a compile dependency on immutables, otherwise the compilation would fail with warning:

warning: unknown enum constant ImplementationVisibility.PACKAGE reason: class file for org.immutables.value.Value$Style$ImplementationVisibility not found error: warnings found and -Werror specified

Another issue is that after upgrading to 2.0.0 immutable classes which depend on conjure generated classes do not rebuild properly when conjure changes.

Run annotation processors as part of the gradle idea task

Current behavior: when switching to a new branch that has different dependencies, I need to run gradle idea to fetch those, and then I need to run Rebuild Project in IntelliJ to run the annotation processors again.

Desired behavior: gradle idea also runs the annotation processors such that checking out a commit and running gradle idea is sufficient to start coding.

autovalue.shaded.* are visible in IDEA when using AutoValue with gradle-processors

By default, using AutoValue with gradle-processors will expose a load of autovalue.shaded.* packages, which if you use will result in ultimate sadness. People manually have to modify Editor > General > Auto Import > Exclude from import and completion in IDEA to stop them being suggested.

Bad generated_src folder in IntelliJ

Following up on my report at inferred/FreeBuilder#245
I tried again. To reproduce, try importing and building my dummy project at
https://github.com/tkruse/beantest/tree/inferred_plugin

Do NOT use the master branch, I added the inferred plugin only in the inferred_plugin branch.

When importing the project in IntelliJ 2016.3.4, then building, I get the following structure:

• beantest
  • generated_src [main]
    • generated_src
      • com ...

which causes all generated classes to be inside package generated_src.com... instead of com...

Also I am slightly annoyed at this being inside the module root, rather than the build folder, and not being cleaned by gradle clean.
Also this ends up having both generated .java and .class files inside build/classes, which is unclean.

The ideal state for me would be for IntelliJ to mirror gradle's behavior, for the generated java sources to be in build/generated_src, and for build/classes only containing .class files.

Feel free to make a PR on my github repo if simple changes to my projects build.gradle can achieve this.

Sorry if my github project example is not minimal, if it would help you a lot, I can reduce it to be minimal.

Gradle 2.12 missing generate_src and generated_testSrc from intellij source directories

Gradle 2.12 does for intellij module

Set<Path> sourceFolders = getSourceDirs().findAll { it.exists() }.collect { path(it) }
Set<Path> generatedSourceFolders = getGeneratedSourceDirs().findAll { it.exists() }.collect { path(it) }
Set<Path> testSourceFolders = getTestSourceDirs().findAll { it.exists() }.collect { path(it) }

which will not add directories until they exist. Would have to generate intellij project, build, regenerate to make it work. Could make directories always with

file(processors.sourceOutputDir).mkdir()
file(processors.testSourceOutputDir).mkdir()

should use a different method to exclude generated classes from FindBugs

at the moment, we remove the generated classes from the findbugs classpath; but this can be problematic if other classes need them (e.g. antipatterns). We should instead find a way to have Findbugs simply ignore the results of analysing the classes.

Plugin should forward processor compiler options (-Akey=value)

What happened?

When specifying annotation processor compiler options in a build file, they are not forwarded to the Eclipse configuration created by the plugin.

What did you want to happen?

Annotation processor options should be forwarded to the Eclipse configuration.

Example:

compileJava
{
	options.compilerArgs += ['-AaddGenerationDate=true'] // Specific to Hibernate JPA meta model generation processor.
}

This should result in the following entry in .settings/org.eclipse.jdt.apt.core.prefs:

org.eclipse.jdt.apt.processorOptions/addGenerationDate=true

Ignoring Immutables not working with latest Baseline findbugs

Baseline version 0.9.1 and above includes an SLF4J findbugs plugin (https://github.com/KengoTODA/findbugs-slf4j), and running findbugsMain with this new plugin will fail with some products, because of a failure to find some Immutable classes.

I've opened a PR to remove this code in gradle-processors #49.The most recent version of Immutables (2.3.7) seems to work much better with findbugs, and products that I've tested which use this updated version of gradle-processors in combination with upgrading Immutables seem to be stable.

Alternatively, we can improve the logic in gradle-processors to be more aggressive when ignoring processors, although it's still unclear to me why the current implementation stopped working for me.

Deprecation warning using recent Gradle 4.4.1

Using a recent Gradle version 4.4.1, I get the following warning on the console:

Using TaskInputs.file() with something that doesn't resolve to a File object has been deprecated and is scheduled to be removed in Gradle 5.0. Use TaskInputs.files() instead.

Seems that a minor refactoring of the plugin is due.

Deprecation warning: "configuration foo was resolved without accessing the project in a safe manner"

What happened?

The configuration :witchcraft-oauth2:allProcessors was resolved without accessing the project in a safe manner. This may happen when a configuration is resolved from a thread not managed by Gradle or from a different project. See https://docs.gradle.org/5.6.4/userguide/troubleshooting_dependency_resolution.html#sub:configuration_resolution_constraints for more details. This behaviour has been deprecated and is scheduled to be removed in Gradle 6.0.

stacktrace includes:

at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:821)
at groovy.lang.GroovyObjectSupport.invokeMethod(GroovyObjectSupport.java:44)
at org.inferred.gradle.ProcessorsPlugin$_configureIdeaPlugin_closure6$_closure27$_closure28.doCall(ProcessorsPlugin.groovy:165)
at java.lang.reflect.Method.invoke(Method.java:566)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:326)

gradle-processors/src/main/groovy/org/inferred/gradle/ProcessorsPlugin.groovy

Line 165 in 1b03d8a

setupIdeaAnnotationProcessing(project, idea.module, it.asNode(), allProcessorConf)

What did you want to happen?

No deprecation warnings I guess!

IDEA-originated imports for multi-project builds broken [IDEA 2017.1.5]

I import using IDEA, and all my projects are multi-project builds where only subprojects contain useful code.
By putting all generated code in the rootDir's generated_src (i.e. ../generated_src from a subproject's module root), they don't compile anymore, since they depend on classes only present in the module.

Why aren't we setting the sources directory to ./generated_src from the module's content root? That's always worked for me before.

Intellij 2016.3 Caused by: groovy.lang.GroovyRuntimeException: replaceNode() can only be used to replace a single node.

Hi,

When importing a gradle project into Intellij 2013.3 i get the error
"Caused by: groovy.lang.GroovyRuntimeException: replaceNode() can only be used to replace a single node."

Looks at the code it looks like line 202 is at fault:
compilerConfiguration.annotationProcessing.replaceNode{
I'm guessing IntelliJ 2016.3 has changed so a newly created project does not contain <annotationProcessing>
</annotationProcessing>
which means compilerConfiguration.annotationProcessing has a count of 0?
If i manually add that to the .idea\compiler.xml file then the loading of the gradle project works.

Provide ability to specify Processors

Not sure if this is possible in any other way. I was looking to specify a processor as in
publicissapient-france/selma#125 , specifically

<processors>
      <processor>lombok.launch.AnnotationProcessorHider$AnnotationProcessor</processor>                   
      <processor>fr.xebia.extras.selma.codegen.MapperProcessor</processor>
</processors>

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

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.

Plugin cannot run under Java7

The plugin is built with Java8, so it cannot be used in Java7. As far as I can tell, there is no reason that this project needs to be built with Java8. Please release a new version which is built with Java7.

Fix Javadoc tasks

Once annotation processing is enabled, Javadoc tasks need to dependOn compile tasks.

Plugin should appear under com.palantir.gradle namespace (rather than org.inferred)

IntelliJ thinks our modules have cycles

We ran into this issue when upgrading from 1.2.8 to 1.2.10

we have two modules: impl and testing-utils with the following dependencies:

testCompile(impl) depends on compile(testing-utils)
compile(testing-utils) dependsOn compile(impl)
testCompile(impl) dependsOn compile(impl)

Both packages have annotations to be processed.

Gradle can build this fine, but intellij mistakenly thinks there is a cycle between impl and testing-utils

App Engine Plugin support?

Hello,

The gradle app engine plugin use the functionalTest source set for functional tests, but it seems your plugin doesn't run annotation processors on it.

Javadoc classpath does not contain processor library

For Immutables, at least, when I generate Javadoc for classes that are annotated with Immutables annotations, I get warnings like this:

javadoc: warning - Class Value.Immutable not found.

org.eclipse.jdt.apt.genSrcDir sets to bin/generated/java in eclipse apt prefs since 1.2.4

Since 1.2.4, org.eclipse.jdt.apt.genSrcDir gets set to bin/generated/java instead of generated_src in org.eclipse.jdt.apt.core.prefs. This breaks the Eclipse workflow and immutable classes no longer get generated on clean projects.

Annotation processors not running consistently in Eclipse

When we run gradle eclipse on a specific project, and import into Eclipse, annotation processors do not appear to run. Only known workaround is to disable and reenable annotation processing for that project.

Upgrade to processors 3.1.0 from 3.0.1 caused certain annotation processors to no longer appear on classpath

What happened?

A number of our internal projects (please message me directly for the internal URLs) took an upgrade to processors 3.1.0. This caused our annotation processing in IntelliJ to fail for all members of the team. Rough reproduction:

buildscript {
    repositories {
        maven {
            url 'https://artifactory/artifactory/release-jar'
        }
    }

    dependencies {
        classpath 'gradle.plugin.org.inferred:gradle-processors:3.1.0'
    }
}


repositories {
    maven {
        url 'https://artifactory/artifactory/all-jar'
    }
}

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

dependencies {
    annotationProcessor "com.palantir.acme:auto-service-processor:1.7.0"
}

We believe this to be caused by:

https://github.com/palantir/gradle-processors/pull/113/files#diff-2a62c8fabf6321047e155acf59a6f8aeL243-R275

What did you want to happen?

Annotation processors in IntelliJ should work.

FindBugs issues warnings for generated code

-

Intellji 2017.3.1 no longer generates Immutable classes to `generated_src`

Processor jars are exported

Remove unnecessary requirement to import 'idea' plugin

Currently if you want to open build.gradle files directly from IntelliJ, you still need to import the 'idea' plugin. This shouldn't be a requirement.

Warning for use of deprecated operator in Gradle 2.8

Seeing this message applying plugin to projects building with Gradle 2.8:

The plus(Iterable) method and using the '+' operator in conjunction with an Iterable object have been deprecated and are scheduled to be removed in 3.0. Please use the plus(FileCollection) method or the '+' operator with a FileCollection object instead.

and running with -Dorg.gradle.deprecation.trace=true shows it's coming from this plugin:

    org.gradle.api.internal.file.AbstractFileCollection$plus.call(Unknown Source)
    org.gradle.api.internal.file.AbstractFileCollection$plus$0.call(Unknown Source)
    org.inferred.gradle.ProcessorsPlugin$_apply_closure2_closure9.doCall(ProcessorsPlugin.groovy:34)
    org.inferred.gradle.ProcessorsPlugin$_apply_closure2.doCall(ProcessorsPlugin.groovy:34)
    org.gradle.api.internal.ClosureBackedAction.execute(ClosureBackedAction.java:67)
    org.gradle.internal.Actions$FilteredAction.execute(Actions.java:202)
    org.gradle.api.internal.DefaultDomainObjectCollection.all(DefaultDomainObjectCollection.java:110)
    org.gradle.api.internal.DefaultDomainObjectCollection.all(DefaultDomainObjectCollection.java:115)
    org.gradle.api.internal.DefaultDomainObjectCollection.withType(DefaultDomainObjectCollection.java:126)
    org.gradle.api.DomainObjectCollection$withType.call(Unknown Source)
    org.inferred.gradle.ProcessorsPlugin.apply(ProcessorsPlugin.groovy:33)
    org.inferred.gradle.ProcessorsPlugin.apply(ProcessorsPlugin.groovy)
    org.gradle.api.internal.plugins.ImperativeOnlyPluginApplicator.applyImperative(ImperativeOnlyPluginApplicator.java:35)
    org.gradle.api.internal.plugins.RuleBasedPluginApplicator.applyImperative(RuleBasedPluginApplicator.java:44)
    org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:144)
    org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:112)
    org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyType(DefaultObjectConfigurationAction.java:112)
    org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:35)
    org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:79)
    org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:135)
    org.gradle.groovy.scripts.DefaultScript.apply(DefaultScript.java:109)
    org.gradle.api.Script$apply$0.callCurrent(Unknown Source)

Inverse of #58

I'm not sure why, but I'm getting bad behavior out of the fix for #58. I don't think I have the "rogue content root" problem observed there, and I think that's in turn causing the fix to break for me.

Here's a sample repo illustrating the problem.

IntelliJ version information:

IntelliJ IDEA 2016.3.3
Build #IC-163.11103.6, built on January 16, 2017
JRE: 1.8.0_112-release-408-b6 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o

Difference from net.ltgt.apt?

Hi,

I created the net.ltgt.apt a few months before your plugin, and was wondering what differences there are between them.

The plus(Iterable<FileCollection>) method and using the '+' operator in conjunction with an Iterable<FileCollection> object have been deprecated

The following deprecation warning appears for me while using Gradle 2.10.

The plus(Iterable<FileCollection>) method and using the '+' operator in conjunction with an Iterable<FileCollection> object have been deprecated and are scheduled to be removed in 3.0. Please use the plus(FileCollection) method or the '+' operator with a FileCollection object instead.