-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Struggling to compile java code with annotation processor produced generated-sources/ #335
Comments
Would you mind sharing your pom.xml? |
Sure. Here it is.
|
Thanks. It looks like it got munged somewhat. Could you make a minimal maven project that has the annotation processor and causes the issue? You can attach as a zip file in the comment. |
I believe I was able to recreate this issue for myself. I may have a workaround for you. I added the compiler option <build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<useIncrementalCompilation>false</useIncrementalCompilation>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.9.2-01</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.4.12-02</version>
</dependency>
</dependencies>
</plugin> |
Thank you! - that makes a bit more progress. I still get a similar failure running ‘mvn test’, but the ‘mvn compile’ at least appears to run several times without error.
We’re also running with the batch compiler inside of IntelliJ, and the tests appear to run there without compilation error - so I’m hopeful of some progress now :). Or, at least a faster development cycle as this compiler should be way faster, even if it’s compiling everything each time.
I’m guessing that we get a lot of benefit from using incremental compilation, especially in a test driven programming environment, so it would still be good to work out to get this resolved generically. (For example, we make need to explicitly exclude certain file paths from the incremental compiler’s perspective, seeing as the annotation processor is managing those generated sources).
Joe
|
Just curious, are you using Maven integration (m2eclipse)? You build test cycle should be able to run without any maven command-line interaction. This should spped up your edit-test cycle. |
On 8 Sep 2017, at 16:12, Eric Milles ***@***.***> wrote:
Just curious, are you using Maven integration (m2eclipse)? You build test cycle should be able to run without any maven command-line interaction. This should spped up your edit-test cycle.
We’re currently using IntelliJ - it’s groovy support is ok, but it uses separate compilers and can take quite a while to run a test against a small code change. We’re trying to switch over to the batch compiler to improve things. We’ve succeeded with most of our projects, but this one that uses annotation processing in one of the external frameworks (RESTX) is blocking the switch over.
Intellij’s groovy-eclipse-batch support appears to work quite well.. and also switching away from GMavenPlus to the batch compiler in our pom’s has fixed a number of issues that we had… so hopefully we can fix it with this project too :).
Cheers,
Joe
|
Okay, thanks for the extra info. Also, which version of the batch compiler are you using?
|
On 8 Sep 2017, at 17:20, Eric Milles ***@***.***> wrote:
Okay, thanks for the extra info. Also, which version of the batch compiler are you using?
The latest, 2.4.12-02.
Joe
|
Can you try installing this to your local maven repository (as org.codehaus.groovy:groovy-eclipse-compiler) and then change your groovy-eclipse-compiler dependency to 2.9.2-SNAPSHOT? I think the stale file scanning should exclude the generated sources directory. But I want to be sure before publishing this to bintray. |
On 8 Sep 2017, at 18:39, Eric Milles ***@***.***> wrote:
Can you try installing this to your local maven repository (as org.codehaus.groovy:groovy-eclipse-compiler) and then change your groovy-eclipse-compiler dependency to 2.9.2-SNAPSHOT? I think the stale file scanning should exclude the generated sources directory. But I want to be sure before publishing this to bintray.
2.9.2-SNAPSHOT.zip <https://github.com/groovy/groovy-eclipse/files/1288672/2.9.2-SNAPSHOT.zip>
At first test, this appears to do the trick. It compiles multiple times now without error.
Thanks!
Joe
|
I've done a bit more testing, and it is definitely better. But, I'm not sure how it is supposed to interact with the compiler flag. With:
it does much less work on subsequent compilations (2 seconds, vs 8 seconds initially). With it set to true it appears to compile the entire code base each time. I would have thought that it would have behaved the other way around. |
useIncrementalCompilation false behavior would be a separate issue. Did your errors for compiling with an annotation processor that generates sources subside?
|
Has there been a release of groovy-eclipse-compiler which contains this fix? If not, is there an ETA for one? We're currently using a copy of your snapshot for production builds, which makes me nervous... |
I've just started using groovy-eclipse-batch (with maven) for a project that also uses a java framework that makes use of an annotation processor to precompile some java classes.
Until now we've been using GMavenPlus. Switching to groovy-batch appears to work with a clean target directory, but when I run 'mvn compile' a second time it complains about classes in the generated-sources/ that were generated by an annotation processor, saying that they already exist.
Is there a simple fix for this?
The errors are of the form:
The class AccountResourceRouter is created during compilation of my AccountResource by an annotation processor in my code base (but not my code).
How do I teach groovy-eclipse-batch not to trip up on these classes? Is there a way?
To be clear, if I run with an empty target/ directory, it works as expected; it's only the second time around that it trips up.
The text was updated successfully, but these errors were encountered: