Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.2
    • Labels:
      None

      Description

      Apt (Annotation Processing Tool) was merged into javac in Java 6. The compiler plugin should support this new functionality, which means supporting the following new arguments:

        -proc:{none,only}          Control whether annotation processing and/or compilation is done.
        -processor <class1>[,<class2>,<class3>...]Names of the annotation processors to run; bypasses default discovery process
        -processorpath <path>      Specify where to find annotation processors
        -s <directory>             Specify where to place generated source files
        -implicit:{none,class}     Specify whether or not to generate class files for implicitly referenced files
        -Akey[=value]              Options to pass to annotation processors
      

      Note that this should supersede the Apt Maven Plugin at Mojo by encompassing all of its functionality:
      http://mojo.codehaus.org/apt-maven-plugin/index.html

        Issue Links

          Activity

          Hide
          Jesse Glick added a comment -

          I think the correct behavior would be to pass something like

          -s $

          {project.basedir}

          /target/generated-sources/annotation-processing

          by default whenever a 269-capable javac is detected.

          Part of Maven's appeal is doing the right thing without being told. Since it knows where generated sources ought to be placed in the project structure, it should tell javac that. As usual it could be permitted to override this directory if you had a particular reason to do so.

          Note that passing -processorpath or -processor is unnecessary if (1) processors are defined in JARs in your project's classpath, (2) they are registered ServiceLoader-style. In such a case they are all run automatically.

          Show
          Jesse Glick added a comment - I think the correct behavior would be to pass something like -s $ {project.basedir} /target/generated-sources/annotation-processing by default whenever a 269-capable javac is detected. Part of Maven's appeal is doing the right thing without being told. Since it knows where generated sources ought to be placed in the project structure, it should tell javac that. As usual it could be permitted to override this directory if you had a particular reason to do so. Note that passing -processorpath or -processor is unnecessary if (1) processors are defined in JARs in your project's classpath, (2) they are registered ServiceLoader-style. In such a case they are all run automatically.
          Hide
          Milos Kleint added a comment -

          the open question with generated-sources/annotation-processing/ output folder setting is how do the xml (or other) files end up in the final binary then.

          For generated .java files, the current solution is to add them to the list of sourceRoots and they get compiled. For non-compilable resources we would have to add them to the list of resources to be processed (but most likely the resources processing phase has already passed by that time).

          Show
          Milos Kleint added a comment - the open question with generated-sources/annotation-processing/ output folder setting is how do the xml (or other) files end up in the final binary then. For generated .java files, the current solution is to add them to the list of sourceRoots and they get compiled. For non-compilable resources we would have to add them to the list of resources to be processed (but most likely the resources processing phase has already passed by that time).
          Hide
          Jesse Glick added a comment -

          I don't think Maven need do anything special.

          1. Non-Java resources (*.xml etc.) should be placed in the regular -d directory: CLASS_OUTPUT.

          2. Generated Java files get compiled by javac automatically in a subsequent round.

          -s is even optional in that without it, javac will just hold generated sources in memory until they have been compiled to bytecode. But it is generally useful to have these saved to disk for debugging and IDE usage.

          Show
          Jesse Glick added a comment - I don't think Maven need do anything special. 1. Non-Java resources (*.xml etc.) should be placed in the regular -d directory: CLASS_OUTPUT. 2. Generated Java files get compiled by javac automatically in a subsequent round. -s is even optional in that without it, javac will just hold generated sources in memory until they have been compiled to bytecode. But it is generally useful to have these saved to disk for debugging and IDE usage.
          Hide
          Milos Kleint added a comment -

          I've added the parameters for -proc, -processor and -s. -s has a default value pointing to target/generated-sources/annotations. they all work only with 1.6+ jdk.

          I'm unclear how -processorpath shall be added. -Akey=value params are probably best to be added via the generic parameter.

          let's consider this done for 2.2 and open specific issues for any missing features.

          Show
          Milos Kleint added a comment - I've added the parameters for -proc, -processor and -s. -s has a default value pointing to target/generated-sources/annotations. they all work only with 1.6+ jdk. I'm unclear how -processorpath shall be added. -Akey=value params are probably best to be added via the generic parameter. let's consider this done for 2.2 and open specific issues for any missing features.
          Hide
          Robert Varga added a comment - - edited

          The proper implementation of -processorpath is really not possible with Maven as I see it at the moment.

          The biggest problem is that Maven does not support a thing like tools classpath, a path which jars which the compiler itself needs but must not be on the compile or test or runtime classpath of the just compiled module.

          This likely could be introduced possibly with yet another scope (or more).

          Not only the processor path, but also the antrun plugin could also benefit from such a new classpath entity.

          Currently the only workaround which exists is defining such dependencies with the provided scope, which at least does not trigger propagation of these dependencies, but it still puts such dependencies on the compilation classpath of the module, so compilation itself is possibly providing incorrect results.

          Of course, this is just my opinion.

          Best regards,

          Robert Varga

          Show
          Robert Varga added a comment - - edited The proper implementation of -processorpath is really not possible with Maven as I see it at the moment. The biggest problem is that Maven does not support a thing like tools classpath, a path which jars which the compiler itself needs but must not be on the compile or test or runtime classpath of the just compiled module. This likely could be introduced possibly with yet another scope (or more). Not only the processor path, but also the antrun plugin could also benefit from such a new classpath entity. Currently the only workaround which exists is defining such dependencies with the provided scope, which at least does not trigger propagation of these dependencies, but it still puts such dependencies on the compilation classpath of the module, so compilation itself is possibly providing incorrect results. Of course, this is just my opinion. Best regards, Robert Varga
          Hide
          Milos Kleint added a comment -

          there is one trick I came up with when working with endorsed libs in j2ee space:

                              <plugin>
                                  <groupId>org.apache.maven.plugins</groupId>
                                  <artifactId>maven-compiler-plugin</artifactId>
                                  <version>2.0.2</version>
                                  <configuration>
                                      <!-- javaee6 contains upgrades of APIs contained within the JDK itself.
                                           As such these need to be placed on the bootclasspath, rather than classpath of the
                                           compiler.
                                           If you don't make use of these new updated API, you can delete the profile.
                                           On non-SUN jdk, you will need to create a similar profile for your jdk, with the similar property as sun.boot.class.path in Sun's JDK.-->
                                      <compilerArguments>
                                          <bootclasspath>${settings.localRepository}/javax/javaee-endorsed-api/6.0/javaee-endorsed-api-6.0.jar${path.separator}${sun.boot.class.path}</bootclasspath>
                                      </compilerArguments>
                                  </configuration>
                                  <dependencies>
                                      <dependency>
                                          <groupId>javax</groupId>
                                          <artifactId>javaee-endorsed-api</artifactId>
                                          <version>6.0</version>
                                      </dependency>
                                  </dependencies>
                              </plugin>
          
          Show
          Milos Kleint added a comment - there is one trick I came up with when working with endorsed libs in j2ee space: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-compiler-plugin </artifactId> <version> 2.0.2 </version> <configuration> <!-- javaee6 contains upgrades of APIs contained within the JDK itself. As such these need to be placed on the bootclasspath, rather than classpath of the compiler. If you don't make use of these new updated API, you can delete the profile. On non-SUN jdk, you will need to create a similar profile for your jdk, with the similar property as sun.boot.class.path in Sun's JDK.--> <compilerArguments> <bootclasspath> ${settings.localRepository}/javax/javaee-endorsed-api/6.0/javaee-endorsed-api-6.0.jar${path.separator}${sun.boot.class.path} </bootclasspath> </compilerArguments> </configuration> <dependencies> <dependency> <groupId> javax </groupId> <artifactId> javaee-endorsed-api </artifactId> <version> 6.0 </version> </dependency> </dependencies> </plugin>
          Hide
          Mark Hobson added a comment -

          I mentioned this on the list, but we could use the plugin's dependencies as the processor path. This is how the apt-maven-plugin currently works.

          Alternatively, to support different usages of plugin dependencies we could specify them using their GAV, like the maven-shade-plugin. For example:

          <plugin>
          	<groupId>org.apache.maven.plugins</groupId>
          	<artifactId>maven-compiler-plugin</artifactId>
          	<configuration>
          		<bootArtifacts>
          			<bootArtifact>myGroup:myLibrary</bootArtifact>
          		</bootArtifacts>
          		<processorArtifacts>
          			<processorArtifact>myGroup:myProcessor</processorArtifact>
          		</processorArtifacts>
          	</configuration>
          	<dependencies>
          		<dependency>
          			<groupId>myGroup</groupId>
          			<artifactId>myLibrary</artifactId>
          			<version>1.0</version>
          		</dependency>
          		<dependency>
          			<groupId>myGroup</groupId>
          			<artifactId>myProcessor</artifactId>
          			<version>1.0</version>
          		</dependency>
          	</dependencies>
          </plugin>
          
          Show
          Mark Hobson added a comment - I mentioned this on the list, but we could use the plugin's dependencies as the processor path. This is how the apt-maven-plugin currently works . Alternatively, to support different usages of plugin dependencies we could specify them using their GAV, like the maven-shade-plugin . For example: <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-compiler-plugin </artifactId> <configuration> <bootArtifacts> <bootArtifact> myGroup:myLibrary </bootArtifact> </bootArtifacts> <processorArtifacts> <processorArtifact> myGroup:myProcessor </processorArtifact> </processorArtifacts> </configuration> <dependencies> <dependency> <groupId> myGroup </groupId> <artifactId> myLibrary </artifactId> <version> 1.0 </version> </dependency> <dependency> <groupId> myGroup </groupId> <artifactId> myProcessor </artifactId> <version> 1.0 </version> </dependency> </dependencies> </plugin>
          Hide
          Parmendra Tyagi added a comment - - edited

          I tried to using this enhancement. But there is a bug while using option proc.
          Here is example

           
          <build>
          		<plugins>
          			<plugin>
          				<groupId>org.apache.maven.plugins</groupId>
          				<artifactId>maven-compiler-plugin</artifactId>
          				<version>2.3.2</version>
          				<configuration>
          					<proc>only</proc>
          					<annotationProcessors>
          						<annotationProcessor>com.annotation.processor.AnnotationProcessor</annotationProcessor>
          					</annotationProcessors>
          					<source>1.6</source>
          					<target>1.6</target>
          				</configuration>
          			</plugin>
          		</plugins>
          	</build>
          

          here i mentioned

           <proc>only</proc> 

          . i.e. it should not compile the code and should do the annotation processing only ( I also cross check this behavior with javac tool of Java 1.6 update 23), but while invoking command

           mvn clean compile 

          , it compile the source code. which is not inline with specification

          Show
          Parmendra Tyagi added a comment - - edited I tried to using this enhancement. But there is a bug while using option proc. Here is example <build> <plugins> <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-compiler-plugin </artifactId> <version> 2.3.2 </version> <configuration> <proc> only </proc> <annotationProcessors> <annotationProcessor> com.annotation.processor.AnnotationProcessor </annotationProcessor> </annotationProcessors> <source> 1.6 </source> <target> 1.6 </target> </configuration> </plugin> </plugins> </build> here i mentioned <proc> only </proc> . i.e. it should not compile the code and should do the annotation processing only ( I also cross check this behavior with javac tool of Java 1.6 update 23), but while invoking command mvn clean compile , it compile the source code. which is not inline with specification
          Hide
          Jesse Glick added a comment -

          Parmendra - your issue should be filed separately in MCOMPILER (can be marked as blocking this one) or it will likely get lost.

          Show
          Jesse Glick added a comment - Parmendra - your issue should be filed separately in MCOMPILER (can be marked as blocking this one) or it will likely get lost.
          Hide
          Dennis Kieselhorst added a comment -
          Show
          Dennis Kieselhorst added a comment - See MCOMPILER-168

            People

            • Assignee:
              Milos Kleint
              Reporter:
              Mark Hobson
            • Votes:
              7 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development