Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add annotationProcessor configurations for each SourceSet #3786
Gradle Core Team Checklist
This is a first shot; documentation needs to be updated, and there should possibly be more integration tests (though the existing tests don't break, and the new behavior is tested by refactoring existing tests to take advantage of it)
I'm not sure the way I "default"
Fwiw, some (existing, untouched) tests apparently require an Oracle JDK (e.g. some tests use javafx) and break with OpenJDK.
Thanks @tbroyer, that was quick :)
I think we'll need to add the deprecation of processors on the compile classpath in the same go to make this change self-contained.
Regarding test coverage there should be one integration test for each scenario:
- user adds processors to the
processorPathconfiguration - only they are used, no warnings
- user has no processors, but some 3rd party library leaks as processor - user is warned that these will be ignored in 5.0
- user has leaking processors, but explicitly sets the processorPath option to an empty collection - no warning is displayed
- user has leaking processors, but explicitly sets the
proc:noneoption - no warning is displayed
- user has no processors and no processors are leaking - no warning is displayed
Does not check for “third party library” specifically, but “processor present in the compile classpath”.
This the default, and is tested automatically by the
Done. That was a fun ride in Gradle internals BTW ;-)
Fwiw, I verified with
Documentation still needs a bit more work (including release notes), but I'd rather have feedback on the code first (and possibly suggestions for the documentation).
I fixed the typos and improved the deprecation message. There were also a few more test expectations I had to adjust.
I made the fallback behavior a bit more specific, so we only fall back when the new default configuration is used. That way users won't get a deprecation warning when they use the
This is very nice and long awaited, thanks for the contribution!
I added a minor thing to fix, but I think we need to be explicit in the release notes that it's a potential breaking change (especially if you already have a
I'm also curious to see how it impacts larger projects in terms of memory usage (because of the creation of additional configurations).
Regarding the name of the configuration, I think I would have preferred
annotationProcessing. In other words, I prefer that the name of the configuration describes the intent (I'm for annotation processing), rather than the consumer (I'm for the annotation processor), because, who knows, other consumers could be interested in using it too. This would also be in line with the names of the new configuration we create (
We'll see the performance impact soon once the branch build is complete. The name
I'll add a note about the new Configuration potentially clashing with one the user already created.
mmm, thanks. About:
Since you just said that the name
I know, but that won't happen with Android, because the Android plugin doesn't add
It could happen with other plugins/custom build scripts, so I'll still add a notice.
added a commit
this pull request
Feb 11, 2018
shouldn't we add s.th. to the figure
shouldn't we link to the blog post instead of "hiding details" and let users "need to google for"?