Maven Compiler Plugin (moved to ASF)
  1. Maven Compiler Plugin (moved to ASF)
  2. MCOMPILER-157

Maven Compiler Plugin should add to compileSourceRoots for next plugins to consider as source directory for generated files

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.2
    • Fix Version/s: 3.2
    • Labels:
      None
    • Environment:
      Java 6
    • Testcase included:
      yes
    • Patch Submitted:
      Yes
    • Number of attachments :
      5

      Description

      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

      1. maven-compiler-plugin-add-compileSourceRoots.patch
        2 kB
        Zoran Regvart
      2. maven-compiler-plugin-addToSourcePathAsWell.patch
        2 kB
        Gleb Frank

        Issue Links

          Activity

          Hide
          Zoran Regvart added a comment -

          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

          Show
          Zoran Regvart added a comment - 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
          Hide
          Zoran Regvart added a comment -

          The failing test example

          Show
          Zoran Regvart added a comment - The failing test example
          Hide
          John Casey added a comment -

          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!

          Show
          John Casey added a comment - 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!
          Hide
          Scott Carey added a comment -

          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

          Show
          Scott Carey added a comment - 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
          Hide
          Dawid Weiss added a comment -

          '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.

          Show
          Dawid Weiss added a comment - '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.

            People

            • Assignee:
              John Casey
              Reporter:
              Zoran Regvart

              Dates

              • Created:
                Updated:
                Resolved: