META-INF/services/javax.annotation.processing.Processor copied before compilation and causes error

Petr Jiricka added a comment - 08/Jan/10 3:34 PM I also hit this issue. My scenario is that the my Maven project provides an annotation processor, and tests for this project use this processor. So when compiling sources, I do not need to run annotation processors; when compiling tests, they need to be compiled. The workaround I found (based on Jesse's straightforward workaround above) is to configure maven-compiler-plugin as follows: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.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> <source>1.6</source> <target>1.6</target> </configuration> </execution> </executions> </plugin>

Petr Jiricka added a comment - 08/Jan/10 3:37 PM Sorry, what I meant is "when compiling tests, processors need to be run". See: http://maven.apache.org/guides/mini/guide-default-execution-ids.html

C Divilly added a comment - 16/Mar/10 10:27 AM I used a variation of the above workaround, in my case I needed the outputs from the annotation processing to be packaged in the final jar not just generated for the testing phase. I added the following to my pom: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.1</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> <executions> <execution> <id>default-compile</id> <configuration> <compilerArgument>-proc:none</compilerArgument> <includes> <include>path/to/annotation/processor/**</include> <include>path/to/annotation/processor/dependencies/**</include> </includes> </configuration> </execution> <execution> <id>compile-everything-else</id> <phase>compile</phase> <goals> <goal>compile</goal> </goals> </execution> </executions> </plugin> more detail on this approach here

Ramon Buckland added a comment - 17/Mar/11 11:30 AM - edited 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>

Jesse Glick added a comment - 07/Jul/11 9:51 AM Regarding -source 1.5 : it is unsafe to pass -processorpath in this case, since the target javac might in fact be from JDK 5 and not recognize this option. (If the compiler plugin went through JSR 199, with javac on the plugin classpath, this would not be an issue.) Regarding a change in javac's behavior: I would not hold my breath. After all, you passed -classpath target/classes:... so that is where it is looking. It is really the responsibility of the invoker to make sure the processor path is correct.

Jesse Glick added a comment - 07/Jul/11 11:07 AM Complete example project working around this problem; for the main sources the processorpath is set to the Maven classpath, so that processors in dependencies can still be used. For test sources, the default behavior is left alone, which is usually OK since tests would not likely define their own processors; processors from dependencies and main sources are still run over test sources.

Kohsuke Kawaguchi added a comment - 07/Jul/11 12:41 PM My workaround is to define a separate Maven module (D) and defines a dummy do-nothing processor of the same fully-qualifled class name. This D module is then added as an optional dependency to my real project (R), so that D won't pollute other projects depending on R. This has the added benefit of making IDEs happy, but the downside is that the test code won't be subject to the annotation processing (which is OK in my case, but may not be OK for others.)