[MCOMPILER-157] Maven Compiler Plugin should add to compileSourceRoots for next plugins to consider as source directory for generated files

[sos-jira-migration-bot]

Zoran Regvart opened MCOMPILER-157 and commented

Maven Compiler Plugin by relying on javac by default, on Java 6 platform includes annotation processors in it's processing, these in end could generate sources that are placed by default in target/generated-sources/annotations. The later should be added to compileSourceRoots so that next plugin in execution would consider those sources.

Please, see the attached test case and consider the attached patch in the next release of maven-compiler-plugin.

thanks,

Zoran

---

Affects: 2.3.2

Attachments:

• failing-test-example.zip (9.60 kB)
• maven-compiler-plugin-add-compileSourceRoots.patch (1.64 kB)
• maven-compiler-plugin-addToSourcePathAsWell.patch (2.19 kB)
• test-case.zip (8.44 kB)
• TestCase2.zip (7.63 kB)

Issue Links:

• MCOMPILER-159 generatedSourcesDirectory should be included in list provided by org.apache.maven.project.MavenProject.getCompileClasspathElements()
  ("is duplicated by")

• MCOMPILER-235 duplicate classes due to MCOMPILER-157 when compiler is called twice or more

• MCOMPILER-236 Compilation error due to MCOMPILER-157 in deploy phase

Remote Links:

• GitHub Pull Request #309
  
• GitHub Pull Request #108
  
• GitHub Pull Request #127
  

7 votes, 17 watchers

[sos-jira-migration-bot]

Zoran Regvart commented

One obvious workaround would be using build helper plugin to add the target/generated-sources/annotations to source path, like:

 
<build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>1.7</version>
        <executions>
          <execution>
            <id>add-source</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>add-source</goal>
            </goals>
            <configuration>
              <sources>
                <source>target/generated-sources/annotations</source>
              </sources>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

[sos-jira-migration-bot]

Jérôme Verstrynge commented

Hi, I have tried to above workaround, but it does not work.

Here is the link to the StackOverflow question I created earlier today: http://stackoverflow.com/questions/6975298/generated-code-not-taken-into-account-in-maven-compile-process.

[sos-jira-migration-bot]

Jérôme Verstrynge commented

To be more precise, when I apply the workaround to the provided test case, it works. Yet, in my application, it does not work. The only difference is that I generate a java file where only a .aj file is generated in the test case.

[sos-jira-migration-bot]

Jérôme Verstrynge commented

I have performed some tests and here are my results:

i) I have checked-out maven-compiler-plugin from the 2.3.3 release locally
ii) I have applied the patch provided by Zoran
iii) I confirm that the issue he reported is solved with this patch (and it does not break existing tests)
iv) However, when generating a java file instead of an aspectj file, the java file is not taken into account in the compiling process (it is not part of the generated .jar)

I am posting another test case to illustrate my point. Keep in mind that I am new to annotation processing, so I may miss something obvious.

[sos-jira-migration-bot]

Jérôme Verstrynge commented

Sorry, I meant 2.3.2 release.

[sos-jira-migration-bot]

Gleb Frank commented

For that matter, why not also add the generated sources directory to the sourcepath as well, so that it gets compiled in the same run? The attached patch (maven-compiler-plugin-addToSourcePathAsWell.patch) builds on the original one to do that.

[sos-jira-migration-bot]

Jesse N. Glick commented

maven-compiler-plugin-addToSourcePathAsWell.patch should not be necessary to my knowledge; 269-generated sources already get compiled in the same run.

[sos-jira-migration-bot]

Martin Franklin commented

I managed to get this working using the helper plugin in combination with a second invocation of the compiler.

Let compiler run normally and generate the annotation processor output.

Then invoke the help plugin at the process-classes lifecycle stage, followed by the compiler again.

Note that the order is important, so that the build-helper gets invoked before the compiler.

<plugins>

		<plugin>
			<groupId>org.codehaus.mojo</groupId>
			<artifactId>build-helper-maven-plugin</artifactId>
			<version>1.7</version>
			<executions>
				<execution>
					<id>add-source</id>
					<phase>process-classes</phase>
					<goals>
						<goal>add-source</goal>
					</goals>
					<configuration>
						<sources>
							<source>target/generated-sources/annotations</source>
						</sources>
					</configuration>
				</execution>
			</executions>
		</plugin>
		<plugin>
			<artifactId>maven-compiler-plugin</artifactId>
			<executions>
				<execution>
					<id>add-source</id>
					<phase>process-classes</phase>
					<goals>
						<goal>compile</goal>
					</goals>

				</execution>
			</executions>
		</plugin>
	</plugins>

[sos-jira-migration-bot]

Martin Franklin commented

Should also state I upgraded to the compiler version 2.5.1 and am using maven 3.0.4

[sos-jira-migration-bot]

Olivier Lamy commented

is there any way to have a failing test case ?

[sos-jira-migration-bot]

Zoran Regvart commented

Olivier, so the two projects that I'll upload are example of a failing situation. The awkwardly named compiler-plugin-simple-annotation-processor is an annotation processor that will generate a .txt file in the with the same directory structure as the annotated class, that is a class annotated with @SimpleAnnotation. The other project is compiler-plugin-annotation-test that has a compile dependency on the former, and a test that checks if the .txt file was indeed created.

If you were to do it on command line using standard java tools you would first compile the sources with javac (including compiler-plugin-simple-annotation-processor.jar and junit.jar) at this point javac would detect the annotation processor and it would create the .txt file (in current directory if no -s option was given). Then you would use java org.junit.runner.JUnitCore org.apache.maven.plugin.AnnotationProcessorTest with classpath pointing to the output of javac (that would include the generated .txt file).

With maven project directory structure and conventions, i.e. source output of annotation processors is target/generated-sources/[test-]annotations, and the fact that current maven compiler plugin does not forward the target/generated-sources/[test-]annotations to compileSourceRoots fails the test. The build helper workaround mentioned above helps, but I think that proper solution is for maven compiler plugin to include the sources it generated (via annotation processors) in classpath for other plugins to have.

This is very similar to my original use case - in which I was generating resources (AspectJ inter type declarations) to be considered by the another plugin after maven compiler plugin (AspectJ maven plugin), that needs these generated resources in classpath. But I imagine that there are other use cases for this as well.

I don't know it this is what you were thinking by a failing test, but I hope it helps.

Zoran

[sos-jira-migration-bot]

Zoran Regvart commented

The failing test example

[sos-jira-migration-bot]

John Dennis Casey commented

adapted failing test case. It's now using a plugin to try to read the generated file from the annotation processor execution. It doesn't make sense that text files in the source roots would be accessible via the JUnit test classpath...

Thanks for the patch and base test case!

[sos-jira-migration-bot]

Scott Carey commented

This seems to be the nexus of a lot of broken behavior related to annotation processing tools. Any chance it would be reverted? It simply appears to be the wrong thing to do. 'mvn clean compile' followed by 'mvn compile' breaks in most builds that have annotation processors that generate classes, from what appears to be this as the root cause.

Adding a project's generated-sources/annotations to downstream projects classpath is probably ok, but adding it to itself appears flawed -- that would imply that 'compile' and 'clean compile' are not expected to have the same input to the compile phase!.

MCOMPILER-235, MCOMPILER-236

[sos-jira-migration-bot]

Dawid Weiss commented

'mvn clean compile' followed by 'mvn compile' breaks in most builds that have annotation processors that generate classes, from what appears to be this as the root cause.

Amen to that. It also happens with just about any JMH project.