Skip to content
This repository has been archived by the owner on Nov 16, 2020. It is now read-only.

Handle all JavaCompile tasks #11

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

ypoluektovich
Copy link

This patch adds more sophisticated handling for Java projects, enabling one to use APT not only in 'compileJava' tasks, but all tasks of type 'JavaCompile'.

Important notes:

  • The default generated source directory name has been changed, as has the mechanism of obtaining said default. The new version enables the project build script to read the default, not only override it.
  • The default directory change affects both Java and Android projects. All the other changes are Java-exclusive, because I have absolutely no experience with Android. Hopefully, if similar functionality is needed, you (or another contributor) can add it easily based on my work.
  • The plugin used to be applied fully inside a project.afterEvaluate invocation. From now on, this is not the case. The reason is that, if the plugin only works after the project is evaluated, the user cannot access configurations and extensions generated by this plugin in the project's build script. To fix that, I moved the creation of configurations and extensions, which are now done at the time of plugin application.
  • This pull-request breaks the tests. I can't fix them, because I can't even run them, because I have groovy 2.2.3 and spock wants 1.8 (or 2.0.5 with the latest release of spock, but it's still too low), and I can't make them become friends :(

In case of Java project, find and APT-ify all JavaCompile tasks,
not just compileJava. Try to auto-guess good names for the
configurations, extensions, helper tasks and output directories.

No new special handling for Android projects.

This commit also changes the default location of generated sources
(for both Java and Android projects).
@ypoluektovich
Copy link
Author

In fact, I thought about it some more, and made the second commit which gets rid of project.afterEvaluate completely for Java projects. Now the configuration application task is available to the user in the project build script too.

My own tests (on my project) show that it works fine.

The dependency is available transitively from gradleApi(),
but it doesn't get propagated to the pom.xml that way.
Explicitly specifying it helps.
@futtetennista
Copy link
Contributor

Thanks very much for the PR! I'm a little busy atm, but I'll make sure I'll have a proper look at this asap.

@confile
Copy link

confile commented Feb 18, 2015

@ypoluektovich Could you please provide an example how I can use APT on tasks of type JavaCompile?

@confile
Copy link

confile commented Feb 18, 2015

@ypoluektovich I get the following error when I try to use your modification:

* What went wrong:
A problem occurred evaluating root project 'apt'.
> org/apache/commons/lang/StringUtils

@ypoluektovich
Copy link
Author

Example 1: https://github.com/ypoluektovich/msyu-logging/blob/master/example/build.gradle
Line 3 is for where I keep my build of this PR, line 4 is to make commons-lang available on APT classpath (you can also use mavenCentral() or your corporate proxying maven repo), line 7 adds the plugin itself, line 11 applies, line 18 adds an annotation processor.

Example 2: https://github.com/ypoluektovich/msyu-logging/blob/master/runtime/build.gradle
Same as above, only this time we need the annotation processor for tests, not for production files. See line 26.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants