Uploaded image for project: 'Maven Compiler Plugin'
  1. Maven Compiler Plugin
  2. MCOMPILER-203

Allow compiler-plugin to specify annotation processor dependencies

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.2, 3.1
    • Fix Version/s: 3.5
    • Labels:
      None
    • Environment:
      Java 6+

      Description

      Right now the status quo for annotation processor artifacts requires one of two actions:

      1. Use an external plugin for annotation processing
      2. Put the annotation processor in as a dependency with provided scope

      The former is suboptimal because the external plugins are clunky and ill-supported, and inflexible/hard to use. The latter is suboptimal because it is often the case that you do not want to leak annotation processor classes on to the application class path.

      It should be possible to add annotation processor dependency artifacts to the compiler plugin configuration such that they are recognized by the annotation processing search algorithm of the compiler, but they do not actually appear on the compilation class path. Ideally they would also be isolated from one another (dependency graphs and all), but that's more of a "nice to have".

        Issue Links

          Activity

          Hide
          thgaw Thorsten Gawantka added a comment - - edited

          An example for this more than suboptimal behavior is the annotation processor for the static static metamodel generator of eclipselink. This processor will add the complete eclipselink dependencies to the compile-classpath which is IMHO MORE than suboptimal.

          Also the version 3.1 of maven-compiler-plugin is affected

          Show
          thgaw Thorsten Gawantka added a comment - - edited An example for this more than suboptimal behavior is the annotation processor for the static static metamodel generator of eclipselink. This processor will add the complete eclipselink dependencies to the compile-classpath which is IMHO MORE than suboptimal. Also the version 3.1 of maven-compiler-plugin is affected
          Hide
          dmlloyd David M. Lloyd added a comment -

          My other personality filed this (probably more verbose and useful) summary on a duplicate bug just today:

          Currently, the compiler plugin searches for annotation processors on the compile class path using the default search algorithm. This can be problematic when having annotation processor JARs or their dependencies on the compile classpath adversely affects compilation behavior, sometimes even making compilation impossible.

          It should be possible to alternatively explicitly give a list of artifacts to pass in to the compiler as the annotation processor path. This would correspond to the standard "-processorpath" option. When given in this way, these artifacts (and their transitive dependencies) would have an isolated class loader which could "see" classes on the compile class path but not be "seen" by classes on the compile class path.

          This list would be defined in the compiler plugin configuration section as a list of artifacts with optional nested exclusions and that sort of thing (no scope though, as annotation processing is only applicable to compilation). I imagine that these artifacts would behave largely similarly to normal dependencies (i.e. subject to <dependencyManagement> sections), and any dependencies which are already on the compile class path would be chosen from the compile class loader rather than being duplicated in the processor class loader.

          Show
          dmlloyd David M. Lloyd added a comment - My other personality filed this (probably more verbose and useful) summary on a duplicate bug just today: Currently, the compiler plugin searches for annotation processors on the compile class path using the default search algorithm. This can be problematic when having annotation processor JARs or their dependencies on the compile classpath adversely affects compilation behavior, sometimes even making compilation impossible. It should be possible to alternatively explicitly give a list of artifacts to pass in to the compiler as the annotation processor path. This would correspond to the standard "-processorpath" option. When given in this way, these artifacts (and their transitive dependencies) would have an isolated class loader which could "see" classes on the compile class path but not be "seen" by classes on the compile class path. This list would be defined in the compiler plugin configuration section as a list of artifacts with optional nested exclusions and that sort of thing (no scope though, as annotation processing is only applicable to compilation). I imagine that these artifacts would behave largely similarly to normal dependencies (i.e. subject to <dependencyManagement> sections), and any dependencies which are already on the compile class path would be chosen from the compile class loader rather than being duplicated in the processor class loader.
          Hide
          dmlloyd David M. Lloyd added a comment -

          An important note here would be that the processors should have their own dependency resolution and class loading scope, so that the versions of dependencies of the annotation processor do not have an impact on the versions used to compile the project itself (or other annotation processors).

          They should have their own <dependencies> and <exclusions> and so on.

          Show
          dmlloyd David M. Lloyd added a comment - An important note here would be that the processors should have their own dependency resolution and class loading scope, so that the versions of dependencies of the annotation processor do not have an impact on the versions used to compile the project itself (or other annotation processors). They should have their own <dependencies> and <exclusions> and so on.
          Hide
          dmlloyd David M. Lloyd added a comment -

          Example configuration:

              <build>
                  <plugins>
                      <plugin>
                          <artifactId>maven-compiler-plugin</artifactId>
                          <configuration>
                              <processors>
                                  <processor>
                                      <groupId>org.blah.processing</groupId>
                                      <artifactId>blah-processor</artifactId>
                                      <version>1.5.3</version>
                                      <processorArguments>
                                           <frobnicate>true</frobnicate>
                                      </processorArguments>
                                      <exclusions>
                                          <!-- top-level exclusions here -->
                                      </exclusions>
                                      <dependencies>
                                          <!-- extra dependencies here -->
                                      </dependencies>
                                  </processor>
                              </processors>
                          </configuration>
                      </plugin>
                  </plugins>
              </build>
          

          If no <processors> element is given, then discovery should behave as it does today; if a <processors> element is present but empty then no annotation processors should be discovered.

          Show
          dmlloyd David M. Lloyd added a comment - Example configuration: <build> <plugins> <plugin> <artifactId> maven-compiler-plugin </artifactId> <configuration> <processors> <processor> <groupId> org.blah.processing </groupId> <artifactId> blah-processor </artifactId> <version> 1.5.3 </version> <processorArguments> <frobnicate> true </frobnicate> </processorArguments> <exclusions> <!-- top-level exclusions here --> </exclusions> <dependencies> <!-- extra dependencies here --> </dependencies> </processor> </processors> </configuration> </plugin> </plugins> </build> If no <processors> element is given, then discovery should behave as it does today; if a <processors> element is present but empty then no annotation processors should be discovered.
          Hide
          dmlloyd David M. Lloyd added a comment -

          Also if no <processorArguments> are given, then the default argument mechanism (inheriting from javac) should be used. If it is given though, then a simple wrapping Processor would be used which provides the given arguments to the delegate.

          Show
          dmlloyd David M. Lloyd added a comment - Also if no <processorArguments> are given, then the default argument mechanism (inheriting from javac) should be used. If it is given though, then a simple wrapping Processor would be used which provides the given arguments to the delegate.
          Hide
          agudian Andreas Gudian added a comment -

          I'm looking into this, but I'll keep it simple for now and only add the ability to specify the -processorpath elements. So no processor-specific argument-handling and inclusion/exclusion patterns - we shouldn't tamper too much with the interaction of processors with the compiler.

          That's how I currently imagine this:

           <configuration>
             <annotationProcessorPaths>
               <path>
                 <groupId>org.sample</groupId>
                 <artifactId>sample-annotation-processor</artifactId>
                 <version>1.2.3</version>
               </path>
               ... more ...
             </annotationProcessorPaths>
           </configuration>
          
          Show
          agudian Andreas Gudian added a comment - I'm looking into this, but I'll keep it simple for now and only add the ability to specify the -processorpath elements. So no processor-specific argument-handling and inclusion/exclusion patterns - we shouldn't tamper too much with the interaction of processors with the compiler. That's how I currently imagine this: <configuration> <annotationProcessorPaths> <path> <groupId>org.sample</groupId> <artifactId>sample-annotation-processor</artifactId> <version>1.2.3</version> </path> ... more ... </annotationProcessorPaths> </configuration>
          Hide
          hudson Hudson added a comment -

          FAILURE: Integrated in maven-plugins #4994 (See https://builds.apache.org/job/maven-plugins/4994/)
          MCOMPILER-203 Allow specifying annotation processor path dependencies (agudian: http://svn.apache.org/viewvc/?view=rev&rev=1723779)

          • maven-compiler-plugin/pom.xml
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/pom.xml
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main/java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main/java/org
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main/java/org/issue
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-processor/src/main/java/org/issue/SimpleAnnotationProcessor.java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/pom.xml
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java/org
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java/org/issue
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java/org/issue/SimpleAnnotation.java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/main/java/org/issue/SimpleObject.java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test/java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test/java/org
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test/java/org/issue
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-user/src/test/java/org/issue/SimpleTestObject.java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/pom.xml
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main/java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main/java/org
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main/java/org/issue
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/annotation-verify/src/main/java/org/issue/SourcePathReadGoal.java
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/invoker.properties
          • maven-compiler-plugin/src/it/MCOMPILER-203-processorpath/pom.xml
          • maven-compiler-plugin/src/it/jdk16-annotation/src/main/resources/META-INF/services/javax.annotation.processing.Processor
          • maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
          • maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/DependencyCoordinate.java
          Show
          hudson Hudson added a comment - FAILURE: Integrated in maven-plugins #4994 (See https://builds.apache.org/job/maven-plugins/4994/ ) MCOMPILER-203 Allow specifying annotation processor path dependencies (agudian: http://svn.apache.org/viewvc/?view=rev&rev=1723779 ) maven-compiler-plugin/pom.xml maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-processor maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-processor/pom.xml maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-processor/src maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-processor/src/main maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-processor/src/main/java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-processor/src/main/java/org maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-processor/src/main/java/org/issue maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-processor/src/main/java/org/issue/SimpleAnnotationProcessor.java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/pom.xml maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/main maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/main/java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/main/java/org maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/main/java/org/issue maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/main/java/org/issue/SimpleAnnotation.java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/main/java/org/issue/SimpleObject.java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/test maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/test/java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/test/java/org maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/test/java/org/issue maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-user/src/test/java/org/issue/SimpleTestObject.java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-verify maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-verify/pom.xml maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-verify/src maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-verify/src/main maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-verify/src/main/java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-verify/src/main/java/org maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-verify/src/main/java/org/issue maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/annotation-verify/src/main/java/org/issue/SourcePathReadGoal.java maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/invoker.properties maven-compiler-plugin/src/it/ MCOMPILER-203 -processorpath/pom.xml maven-compiler-plugin/src/it/jdk16-annotation/src/main/resources/META-INF/services/javax.annotation.processing.Processor maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/DependencyCoordinate.java
          Hide
          dmlloyd David M. Lloyd added a comment -

          Does the proposed solution isolate the processor paths from each other?

          Show
          dmlloyd David M. Lloyd added a comment - Does the proposed solution isolate the processor paths from each other?
          Hide
          dmlloyd David M. Lloyd added a comment -

          Also, is there a way to override or exclude transitive dependencies of the processor path entries?

          Show
          dmlloyd David M. Lloyd added a comment - Also, is there a way to override or exclude transitive dependencies of the processor path entries?
          Hide
          agudian Andreas Gudian added a comment -

          From the new documentation:

          Classpath elements to supply as annotation processor path. If specified, the compiler will detect annotation processors only in those classpath elements. If omitted, the default classpath is used to detect annotation processors. The detection itself depends on the configuration of annotationProcessors.

          Each classpath element is specified using their Maven coordinates (groupId, artifactId, version, classifier, type). Transitive dependencies are added automatically. Example:

          <configuration>
            <annotationProcessorPaths>
              <path>
                <groupId>org.sample</groupId>
                <artifactId>sample-annotation-processor</artifactId>
                <version>1.2.3</version>
              </path>
              <!-- ... more ... -->
            </annotationProcessorPaths>
          </configuration>
          

          Transitive dependencies are resolved. Exclusions can't be defined, and just as with plugin-dependencies, the dependencyManagement section does NOT have any influence on these processor classpath elements.

          As to your question with the isolation: it's not possible to hand over different sets of processor classpaths to javac - there is only one -processorpath option there.
          If you have multiple processors that have conflicting dependencies, then please take that up with the providers of those processors. Both Javac and the Eclipse JDT compiler implementation only support that one processor path and developers of such processors should be aware of that. That's actually a good use case for the maven-shade-plugin, where dependencies are mapped to private packages and inlined into the jar (the so-called fat-jar). That's how it's done for example in the MapStruct processor.

          Show
          agudian Andreas Gudian added a comment - From the new documentation: Classpath elements to supply as annotation processor path. If specified, the compiler will detect annotation processors only in those classpath elements. If omitted, the default classpath is used to detect annotation processors. The detection itself depends on the configuration of annotationProcessors. Each classpath element is specified using their Maven coordinates (groupId, artifactId, version, classifier, type). Transitive dependencies are added automatically. Example: <configuration> <annotationProcessorPaths> <path> <groupId>org.sample</groupId> <artifactId>sample-annotation-processor</artifactId> <version>1.2.3</version> </path> <!-- ... more ... --> </annotationProcessorPaths> </configuration> Transitive dependencies are resolved. Exclusions can't be defined, and just as with plugin-dependencies, the dependencyManagement section does NOT have any influence on these processor classpath elements. As to your question with the isolation: it's not possible to hand over different sets of processor classpaths to javac - there is only one -processorpath option there. If you have multiple processors that have conflicting dependencies, then please take that up with the providers of those processors. Both Javac and the Eclipse JDT compiler implementation only support that one processor path and developers of such processors should be aware of that. That's actually a good use case for the maven-shade-plugin, where dependencies are mapped to private packages and inlined into the jar (the so-called fat-jar). That's how it's done for example in the MapStruct processor .
          Hide
          dmlloyd David M. Lloyd added a comment -

          The idea is to not use javac anymore, or at most, do not support processor specification for javac, which I believe is consistent with the current design climate (in fact I'm not even sure that the latest version supports using javac anymore, does it?). Instead the javax.tools API should be used, as it is not only far more flexible but also solves a number of other unrelated bugs relating to output parsing, error reporting, etc.

          Using this API, it is trivial to specify isolated processors.

          Show
          dmlloyd David M. Lloyd added a comment - The idea is to not use javac anymore, or at most, do not support processor specification for javac, which I believe is consistent with the current design climate (in fact I'm not even sure that the latest version supports using javac anymore, does it?). Instead the javax.tools API should be used, as it is not only far more flexible but also solves a number of other unrelated bugs relating to output parsing, error reporting, etc. Using this API, it is trivial to specify isolated processors.
          Hide
          agudian Andreas Gudian added a comment -

          The javac executable and what's behind javax.tools is very much the same in terms of options.

          For example, I'm not aware of a way to specify isolated processors or paths with that API. You'd have to invoke multiple rounds with proc:only followed with proc:none with either. the API or the javac process to do something like that. Is that what you mean?

          Show
          agudian Andreas Gudian added a comment - The javac executable and what's behind javax.tools is very much the same in terms of options. For example, I'm not aware of a way to specify isolated processors or paths with that API. You'd have to invoke multiple rounds with proc:only followed with proc:none with either. the API or the javac process to do something like that. Is that what you mean?
          Hide
          agudian Andreas Gudian added a comment -

          Oh and you still can use the external javac in the current version, which is important for example for toolchain-support. So I'd favour to support the configuration options for both variants, the (faster) API and the bulletproof/toolchain-supporting forked javac.

          Show
          agudian Andreas Gudian added a comment - Oh and you still can use the external javac in the current version, which is important for example for toolchain-support. So I'd favour to support the configuration options for both variants, the (faster) API and the bulletproof/toolchain-supporting forked javac.
          Hide
          dmlloyd David M. Lloyd added a comment -

          All you have to do with the API is call javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can be instantiated from an isolated class loader according to any rules or strategy that you like. To specify isolated options, you can simply wrap each Processor with one that provides the specific arguments that were configured to the delegate processor on init().

          I'm not aware of a use case that external javac solves which cannot be solved with the javax.tools API, given how old that API is now.

          Show
          dmlloyd David M. Lloyd added a comment - All you have to do with the API is call javax.tools.JavaCompiler.CompilationTask#setProcessors(). Each processor can be instantiated from an isolated class loader according to any rules or strategy that you like. To specify isolated options, you can simply wrap each Processor with one that provides the specific arguments that were configured to the delegate processor on init(). I'm not aware of a use case that external javac solves which cannot be solved with the javax.tools API, given how old that API is now.
          Hide
          agudian Andreas Gudian added a comment -

          Ah, ok, right. I guess that could work for the javax.tools case.

          Regarding the external javac, the use case is for whenever you need to compile / test your code with a different compiler than the JDK used to execute Maven - e.g. for building code for a JDK version older than the runtime-requirements of the maven version or of some plugins, a JDK of a different vendor, or for running integration tests of annotation-processors against multiple different JDKs within one build...
          So it's still an important capability to have and to keep.

          Anyway, I think we're getting a little off-topic and that separation idea should be discussed in MCOMPILER-207 after all - I don't see it within the scope of this issue.

          Show
          agudian Andreas Gudian added a comment - Ah, ok, right. I guess that could work for the javax.tools case. Regarding the external javac, the use case is for whenever you need to compile / test your code with a different compiler than the JDK used to execute Maven - e.g. for building code for a JDK version older than the runtime-requirements of the maven version or of some plugins, a JDK of a different vendor, or for running integration tests of annotation-processors against multiple different JDKs within one build... So it's still an important capability to have and to keep. Anyway, I think we're getting a little off-topic and that separation idea should be discussed in MCOMPILER-207 after all - I don't see it within the scope of this issue.
          Hide
          dmlloyd David M. Lloyd added a comment -

          Pity. This feature isn't even useful to me without isolation - we may soon rely on having multiple, non-conflicting annotation processors in various of our projects. Without isolation this is just one step removed from having your processors on the class path. The difference is that processors are generally more likely to have dependencies that conflict with other processors than to have dependencies that conflict with the class path.

          Thanks for looking at this, in any event. My own effort stalled as I did not know how to use the internal Maven APIs to set up isolated class loaders anyway.

          Show
          dmlloyd David M. Lloyd added a comment - Pity. This feature isn't even useful to me without isolation - we may soon rely on having multiple, non-conflicting annotation processors in various of our projects. Without isolation this is just one step removed from having your processors on the class path. The difference is that processors are generally more likely to have dependencies that conflict with other processors than to have dependencies that conflict with the class path. Thanks for looking at this, in any event. My own effort stalled as I did not know how to use the internal Maven APIs to set up isolated class loaders anyway.
          Hide
          agudian Andreas Gudian added a comment -

          David M. Lloyd: my advice would be make sure the processors don't bring any dependencies - either by suggesting that to the developers of them, or by creating your own repackaged version using the maven-shade-plugin. It's not too complicated and you'll have less trouble when trying to integrate it into further tooling (e.g. in IDEs - working with annotation processors with the Eclipse incremental compiler is really cool).
          Ooor (but that may not work in every case), you add multiple executions of the maven-compiler-plugin to your pom, each of them using a different processor and with proc:only... But I get that it's not what you're looking for :-/

          Show
          agudian Andreas Gudian added a comment - David M. Lloyd : my advice would be make sure the processors don't bring any dependencies - either by suggesting that to the developers of them, or by creating your own repackaged version using the maven-shade-plugin. It's not too complicated and you'll have less trouble when trying to integrate it into further tooling (e.g. in IDEs - working with annotation processors with the Eclipse incremental compiler is really cool). Ooor (but that may not work in every case), you add multiple executions of the maven-compiler-plugin to your pom, each of them using a different processor and with proc:only ... But I get that it's not what you're looking for :-/
          Hide
          dmlloyd David M. Lloyd added a comment -

          I guess I'll have to figure out some kind of workaround, yeah.

          Show
          dmlloyd David M. Lloyd added a comment - I guess I'll have to figure out some kind of workaround, yeah.
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in maven-plugins #5001 (See https://builds.apache.org/job/maven-plugins/5001/)
          MCOMPILER-203 Update plexus-compiler to released version 2.7 (agudian: http://svn.apache.org/viewvc/?view=rev&rev=1724892)

          • maven-compiler-plugin/pom.xml
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in maven-plugins #5001 (See https://builds.apache.org/job/maven-plugins/5001/ ) MCOMPILER-203 Update plexus-compiler to released version 2.7 (agudian: http://svn.apache.org/viewvc/?view=rev&rev=1724892 ) maven-compiler-plugin/pom.xml
          Hide
          natros Filipe Sousa added a comment -

          Switching from 3.1 to 3.5 blows the compiler. I don't have a small test that I can reproduce. But I have some medium/large private projects that cannot compile with 3.5

          Not sure if this is bug in jdk8 or maven-compiler-plugin.

          [INFO] --- maven-compiler-plugin:3.5:compile (default-compile) @ rfid-server ---
          [INFO] Compiling 394 source files to /Users/fsousa/Projects/ipb/rfid/rfid-server/target/classes
          An exception has occurred in the compiler (1.8.0_72). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you.
          java.lang.IllegalStateException: endPosTable already set
          	at com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
          	at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
          	at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
          	at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
          	at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892)
          	at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
          	at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
          	at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
          	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
          	at com.sun.tools.javac.main.Main.compile(Main.java:523)
          	at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
          	at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
          	at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
          	at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:171)
          	at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:884)
          	at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
          	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
          	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
          	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
          	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
          	at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:352)
          	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:197)
          	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
          	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
          	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
          	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
          	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
          	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
          	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
          	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
          	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
          	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
          	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
          	at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
          	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
          	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          	at java.lang.reflect.Method.invoke(Method.java:498)
          	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
          	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
          	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
          	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
          	at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
          

          mvn --version
          Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00)
          Maven home: /usr/local/Cellar/maven/3.3.9/libexec
          Java version: 1.8.0_72, vendor: Oracle Corporation
          Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre
          Default locale: en_US, platform encoding: UTF-8
          OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"

          Show
          natros Filipe Sousa added a comment - Switching from 3.1 to 3.5 blows the compiler. I don't have a small test that I can reproduce. But I have some medium/large private projects that cannot compile with 3.5 Not sure if this is bug in jdk8 or maven-compiler-plugin. [INFO] --- maven-compiler-plugin:3.5:compile (default-compile) @ rfid-server --- [INFO] Compiling 394 source files to /Users/fsousa/Projects/ipb/rfid/rfid-server/target/classes An exception has occurred in the compiler (1.8.0_72). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.IllegalStateException: endPosTable already set at com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136) at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667) at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892) at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129) at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138) at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125) at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:171) at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:884) at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:352) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:197) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) at org.codehaus.classworlds.Launcher.main(Launcher.java:47) mvn --version Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T16:41:47+00:00) Maven home: /usr/local/Cellar/maven/3.3.9/libexec Java version: 1.8.0_72, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.11.4", arch: "x86_64", family: "mac"
          Hide
          agudian Andreas Gudian added a comment -

          Filipe Sousa, please don't hijack this issue . But without knowing what exactly you're doing and what you've changed, it's hard for me to help you. But just taking a shot - in case you get this error when running mvn without clean, e.g. mvn install instead of mvn clean install, you could have gotton under the wheels of MCOMPILER-235. At least I got the exact same stacktrace when I just tried to reproduce it (mvn clean compile with annotation processors present, and then immediately followed by mvn compile). If this the case for you, you're welcome to chime in on MCOMPILER-235. Otherwise, please continue the discussion on users@maven.apache.org, or create a new issue here in Jira.

          Thanks!

          Show
          agudian Andreas Gudian added a comment - Filipe Sousa , please don't hijack this issue . But without knowing what exactly you're doing and what you've changed, it's hard for me to help you. But just taking a shot - in case you get this error when running mvn without clean , e.g. mvn install instead of mvn clean install , you could have gotton under the wheels of MCOMPILER-235 . At least I got the exact same stacktrace when I just tried to reproduce it ( mvn clean compile with annotation processors present, and then immediately followed by mvn compile ). If this the case for you, you're welcome to chime in on MCOMPILER-235 . Otherwise, please continue the discussion on users@maven.apache.org, or create a new issue here in Jira. Thanks!
          Hide
          t.broyer Thomas Broyer added a comment -

          FWIW, one big issue with this (but which is not imputable to the plugin, but to Maven's design), is that dependencies declared in the `annotationProcessorPaths` don't participate in the Maven execution graph analysis, such that Maven cannot guarantee that within a reactor build annotation processors will actually be built before the modules that use them.

          Show
          t.broyer Thomas Broyer added a comment - FWIW, one big issue with this (but which is not imputable to the plugin, but to Maven's design), is that dependencies declared in the `annotationProcessorPaths` don't participate in the Maven execution graph analysis, such that Maven cannot guarantee that within a reactor build annotation processors will actually be built before the modules that use them.

            People

            • Assignee:
              agudian Andreas Gudian
              Reporter:
              dmlloyd David M. Lloyd
            • Votes:
              2 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development