[
http://jira.codehaus.org/browse/MCOMPILER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260564#action_260564
]
Ramon Buckland commented on MCOMPILER-97:
-----------------------------------------
I needed to do something similar.
I have a Unit Test which actually runs my Processor by calling the JavaCompiler.
{{{
@Test
public void fullComprehensiveTest() {
...
// Get an instance of java compiler
JavaCompiler compiler = ToolProvider.getSystemJavaCompiler();
// Get a new instance of the standard file manager implementation
StandardJavaFileManager fileManager =
compiler.getStandardFileManager(null, null, null);
List<String> options = new ArrayList<String>();
options.add("-d");
File outputDir = new File("target", "processor-test");
outputDir.mkdirs();
options.add(outputDir.getAbsolutePath());
options.add("-s");
options.add(outputDir.getAbsolutePath());
// Get the list of java file objects
SrcFilesTestClass srcFiles = new SrcFilesTestClass();
System.out.println(">> testing: files to run annotation test on (only
some have annotations): ");
for (String f : srcFiles.srcFiles()) {
System.out.println(f);
}
Iterable<? extends JavaFileObject> compilationUnits1 =
fileManager.getJavaFileObjects(srcFiles.srcFiles());
StringWriter output = new StringWriter();
CompilationTask task = compiler.getTask(output, fileManager, null,
options, null, compilationUnits1);
// Create a list to hold annotation processors
LinkedList<AbstractProcessor> processors = new
LinkedList<AbstractProcessor>();
// Add an annotation processor to the list
processors.add(new VannitationOneToOneProcessor());
processors.add(new VannitationManyToOneProcessor());
// Set the annotation processor to the compiler task
task.setProcessors(processors);
// Perform the compilation task.
// the compiler will return false for us because the files we are
// creating won't compile as
// we don't have the required fields.
task.call();
// now some tests .. we will just validate that
...
}
}}}
So .. to ensure that the processor does not run in my package from maven, and
that I control it (maven via surefire runs it), I -proc:none on the compile
test also.
{{{
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<executions>
<execution>
<id>default-compile</id>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
<source>1.6</source>
<target>1.6</target>
</configuration>
</execution>
<execution>
<id>default-testCompile</id>
<configuration>
<compilerArgument>-proc:none</compilerArgument>
<source>1.6</source>
<target>1.6</target>
</configuration>
</execution>
</executions>
</plugin>
}}}
> META-INF/services/javax.annotation.processing.Processor copied before
> compilation and causes error
> --------------------------------------------------------------------------------------------------
>
> Key: MCOMPILER-97
> URL: http://jira.codehaus.org/browse/MCOMPILER-97
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
> Affects Versions: 2.0.2
> Environment: Ubuntu 8.10, JDK 6.
> Reporter: Jesse Glick
> Attachments: maven-6647998-test.zip
>
>
> It is tricky to compile a Maven module which defines a (269-compliant)
> annotation processor. If you write the code for the processor in
> src/main/java and register it in src/main/resources,
> META-INF/services/javax.annotation.processing.Processor is copied to
> target/classes first, and then javac is run. But javac is given
> target/classes in -classpath, so it tries to load the processor, which of
> course has not been compiled yet - a chicken-and-egg problem.
> The most straightforward workaround is to specify
> <compilerArgument>-proc:none</compilerArgument> in your POM. This will only
> work, however, if the module does not use any annotation processors defined
> in dependencies. If it does, there may be some other trick involving
> -processorpath and Maven variable substitution to insert the dependency
> classpath.
> Switching the order of resources:resources and compiler:compile would help -
> at least a clean build would work - though it could still cause problems in
> incremental builds. Better would be for the compiler plugin to pass
> -processorpath based on the dependency classpath (i.e. -classpath minus
> target/classes) when using -source 1.6 or higher.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
