[MCOMPILER-369] Adding module-info.java breaks JMH annotation processor

[jira-importer]

Gili opened MCOMPILER-369 and commented

1. Open testcase
2. Run clean install. Notice that the benchmarks run.
3. Open pom.xml and comment-out the <annotationProcessorPaths> section.
4. Run clean install. Notice that the annotation processor does not run and the benchmarks break.
5. Delete/rename module-info.java.
6. Run clean install. Notice that the benchmarks work again.

The documentation for <annotationProcessorPaths> states that by default annotation processors are detected from the classpath. It seems that adding module-info.java breaks that somehow, which is weird/unexpected because JMH exists as a dependency outside the newly-declared module.

I did two things to prove that the annotation processor is not being invoked in step 4:

1. Notice that target/test-classes/META-INF is not created.
2. Place a breakpoint in org.openjdk.jmh.generators.BenchmarkProcessor and notice that it is never even constructed.

I tried digging into the maven-compiler-plugin and plexus-compiler source-code but couldn't figure out where the problem is. The only workaround I found is to specify annotationProcessorPaths manually but it took me half a day to track down this problem.

Any idea what is going on? Is this a bug in the plugin(s)?

---

Affects: 3.8.0

Attachments:

• annotation-processor-jigsaw.zip (2.02 kB)

1 votes, 6 watchers

[jira-importer]

Gili commented

I found a related discussion: http://jigsaw-dev.1059479.n5.nabble.com/Annotation-processors-and-the-processor-module-path-tp5714320p5714342.html

Alan Bateman writes:

When you deploy annotation processors on the --processor-module-path  then javac needs to resolve the annotation processor modules as part of  creating the dynamic configuration. The issue with the dependency on  java.xml.bind is that it's not in the boot layer and it's also not  observable on the processor module path. There is no support at this  time for augmenting the boot layer once it is created, also javac does  not attempt to resolve these modules from the original module path and  system image that were used to start the VM. So for now at least,  running with -J--add-modules=java.xml.bind is the only way to get this  to work. 

[jira-importer]

Robert Scholte commented

It looks like this can't be fixed in the code. I suggest to add an entry to the Frequently Asked Questions page.

[jira-importer]

Gili commented

Now that nabble is dead, the above discussion can be found at https://mail.openjdk.org/pipermail/jigsaw-dev/2016-November/010201.html