Add apt support for Java 6

I think the correct behavior would be to pass something like

-s $

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

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

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.

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.

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

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>

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>

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

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