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

[jira-importer]

Jesse N. Glick opened MCOMPILER-97 and commented

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.

---

Affects: 2.0.2

Attachments:

• maven-6647998-test.zip (7.64 kB)
• MCOMPILER-97-workaround.zip (5.98 kB)

Issue Links:

• MCOMPILER-134 add support for jdk 6 javac -processorpath parameter

• MCOMPILER-98 -sourcepath not passed to javac ("is depended upon by")

13 votes, 24 watchers

[jira-importer]

Petr Jiricka commented

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>

[jira-importer]

Petr Jiricka commented

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

[jira-importer]

cdivilly commented

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

[jira-importer]

Ramon Buckland commented

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>

[jira-importer]

Kohsuke Kawaguchi commented

The original description of the issue says "when using -source 1.6 or higher" in the end, but that doesn't make sense. The question is if the build is using JDK6 or above to compile, not whether it's producing 1.6 compatible files or 1.5 compatible files. JSR-269 still kicks in with -source 1.5.

Note that the problem is beyond just the maven-compiler-plugin. IDEs are also affected by this --- for example when IntelliJ IDEA compiles a subset of source files that are updated, it automatically adds the class file folder to classpath, and you get the same problem.

I wonder if this calls for a change in javac --- perhaps it shouldn't look for its own output directory to look for annotation processors. I can't think of a valid use case for doing that.

[jira-importer]

Jesse N. Glick commented

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.

[jira-importer]

Jesse N. Glick commented

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.

[jira-importer]

Kohsuke Kawaguchi commented

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

[jira-importer]

Michael Osipov commented

This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.

[jira-importer]

Ivan Rakov commented

I have just tried to compile my annotation processor with the latest maven version (3.3.3), results are the same:

[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider com.devexperts.egen.processor.AutoSerializableProcessor not found
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.945 s
[INFO] Finished at: 2015-09-09T13:20:36+03:00
[INFO] Final Memory: 17M/212M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-cli) on project egen: Compilation failure
[ERROR] Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider com.devexperts.egen.processor.AutoSerializableProcessor not found

As before, workaround with <compilerArgument>-proc:none</compilerArgument> works. Seems like this issue is still present.

[jira-importer]

Michael Osipov commented

Reopened as per Ivan's comment.

[jira-importer]

Andreas Gudian commented

I'm closing this as "Not A Problem", as it's just how a) the default lifecycle works, b) javac works. And (most importantly), you can just list the annotation-processors to execute specifically (for a while now) and/or specify the processorPath explicitly (as of version 3.5) - either one of them prevents javac from auto-detecting processors from the build classpath.

Hope that helps.

[jira-importer]

Stephen Buergler commented

If anyone else has this issue: If you use an annotation processor to create the META-INF/services/javax.annotation.processing.Processor file then I've noticed that everything kind of just works. The file isn't there when the main sources are being compiled and it is there when the test sources are being compiled. This is the annotation processor I have been using: https://github.com/kohsuke/metainf-services

Edit: Hmm.. just realized the author of that project posted comments here. I've noticed that I have had to clean the project if I build a bad version and the meta-inf services file is still there but other than that this works fine.

[jira-importer]

Basil Crow commented

Andreas Gudian I disagree with the assessment of this ticket as "Not a Problem". True, one could list the annotation processors or processor path explicitly, but this results in a POM that is hard to develop and maintain (in the sense that one would have to construct this enumeration and keep it up-to-date) in contrast with a POM that does not list them explicitly and instead relies on the default discovery behavior. Jesse N. Glick's original suggestion resolves this problem nicely:

Better would be for the compiler plugin to pass -processorpath based on the dependency classpath (i.e. -classpath minus target/classes)

In my opinion this ticket should be reopened.

[jira-importer]

Olivier Lamy commented

Reopened per Basil's comment

[jira-importer]

Matt Nelson commented

one could list the annotation processors or processor path explicitly, but this results in a POM that is hard to develop and maintain (in the sense that one would have to construct this enumeration and keep it up-to-date) in contrast with a POM that does not list them explicitly and instead relies on the default discovery behavior

It appears that this is the direction that javac is heading towards. https://inside.java/2023/10/23/quality-heads-up/