Community
Participate
Working Groups
In org.eclipse.jdt.internal.compiler.batch.Main.initializeAnnotationProcessorManager() the following code is present: protected void initializeAnnotationProcessorManager() { try { Class c = Class.forName("org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorManager"); //$NON-NLS-1$ AbstractAnnotationProcessorManager annotationManager = (AbstractAnnotationProcessorManager) c.newInstance(); annotationManager.configure(this, this.expandedCommandLine); annotationManager.setErr(this.err); annotationManager.setOut(this.out); this.batchCompiler.annotationProcessorManager = annotationManager; } catch (ClassNotFoundException e) { // ignore } catch (InstantiationException e) { // should not happen throw new org.eclipse.jdt.internal.compiler.problem.AbortCompilation(); } catch (IllegalAccessException e) { // should not happen throw new org.eclipse.jdt.internal.compiler.problem.AbortCompilation(); } catch(UnsupportedClassVersionError e) { // report a warning this.logger.logIncorrectVMVersionForAnnotationProcessing(); } } If someone calls the eclipse compiler programmatically or from command line, and does not have the org.eclipse.jdt.compiler.apt on the classpath, the compiler simply ignores annotation processors without a single output or error message. This happens even if the user defines the "-processors" argument. What I would expect: If there is any annotation processor on the classpath and/or "-processors" is given and the org.eclipse.jdt.compiler.apt jar is missing, the compilation should fail.
New Gerrit change created: https://git.eclipse.org/r/56869
Gerrit change https://git.eclipse.org/r/56869 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=7054404d86f8354c8460ac79576bdc4596325207
Thanks for the report, I found this to be similar in nature as bug 478225, so released the fix together. Unfortunately I couldn't replicate it perfectly within unit test, so this doesn't get a testcase.
Verified for 4.6 M3 using I20151026-2000 build
This change broke our build.
I am still digging in to figure out what's going on, but a product build that was working fine with Neon M2 fails with Neon M3. I've traced the failure message to this change.
Note that the regression is in the context of PDE Build.
I checked build.xml generated by PDE build for the plugin that's failing, but that didn't yield any clues. I don't see anything in project metadata that's explicitly enabling annotation processing, nor anything regarding this in the build file. The odd thing is that this isn't causing all plugins to fail to build, but I haven't been able to figure out the triggering condition.
(In reply to Konstantin Komissarchik from comment #5) > This change broke our build. For starters: What exactly is the problem you are seeing?
We see the following when building our product with Neon M3. The issue was not there in Neon M2. [java] @dot: [java] [mkdir] Created dir: d:\WS\40\trunk\neon\plugins\oracle.eclipse.tools.webtier.trinidad.ui\@dot [java] [javac] Compiling 3 source files to d:\WS\40\trunk\neon\plugins\oracle.eclipse.tools.webtier.trinidad.ui\@dot [java] [javac] Unable to load annotation processing manager org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorManager from classpath. [java] [javac] [java] [javac] Compilation failed. Compiler errors are available in d:\WS\40\trunk\neon\plugins\oracle.eclipse.tools.webtier.trinidad.ui/@dot.log [java] [java] BUILD FAILED The message that fails the build is the message introduced by this fix. See Git diff.
(In reply to Konstantin Komissarchik from comment #10) > We see the following when building our product with Neon M3. The issue was > not there in Neon M2. > > [java] @dot: > [java] [mkdir] Created dir: > d:\WS\40\trunk\neon\plugins\oracle.eclipse.tools.webtier.trinidad.ui\@dot > [java] [javac] Compiling 3 source files to > d:\WS\40\trunk\neon\plugins\oracle.eclipse.tools.webtier.trinidad.ui\@dot > [java] [javac] Unable to load annotation processing manager > org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorManager > from classpath. > [java] [javac] > [java] [javac] Compilation failed. Compiler errors are available in > d:\WS\40\trunk\neon\plugins\oracle.eclipse.tools.webtier.trinidad.ui/@dot.log > [java] > [java] BUILD FAILED > > The message that fails the build is the message introduced by this fix. See > Git diff. Are you sure that the new message fails the build? The next message seems to indicate you have compile errors. What do you find in that log? If that code location is reached, this seems to imply that your build was wrongly configured also before, just the way we handle this has changed.
> Are you sure that the new message fails the build? I am positive. @dot.log contains only this message. If you look at the Git diff you will that an exception in the compiler that was previously ignored, now results in AbortCompilation exception.
> If that code location is reached, this seems to imply that your build was > wrongly configured also before, just the way we handle this has changed. I can't rule that out, but I haven't been able to find the variable that's causing this to fail. Note the following... 1. The build script for the project is generated by PDE Build. 2. The project is extremely simple, composed of three source files, with no annotations besides @Override. 3. The project is not configured for annotation processing. 4. There is nothing that I see that's asking for annotation processing. 5. I have verified that PDE Build is adding org.eclipse.jdt.compiler.apt bundle to the classpath given to the compiler. I can attach the generated build script, if that would be helpful somehow. 6. The build failure reproduces consistently, across machines and across operating systems.
(In reply to Konstantin Komissarchik from comment #13) > 3. The project is not configured for annotation processing. > 4. There is nothing that I see that's asking for annotation processing. > 5. I have verified that PDE Build is adding org.eclipse.jdt.compiler.apt > bundle to the classpath given to the compiler. All of those mean that the configuration is alright and the exception shouldn't happen. But please attach the script so we can find out what is going on.
Created attachment 257771 [details] Build script This is the build script that PDE Build generates for the project that's failing to build.
I continue to be at a loss to explain what's causing the compiler to trip on this particular project. There is absolutely nothing remarkable about it that I can see. I have removed the JDT project-level settings file, but that didn't help. I loaded the project in Eclipse with Neon M3 target and confirmed that there are no compilation errors visible in the IDE.
(In reply to Konstantin Komissarchik from comment #16) > I continue to be at a loss to explain what's causing the compiler to trip on > this particular project. There is absolutely nothing remarkable about it > that I can see. I have removed the JDT project-level settings file, but that > didn't help. I loaded the project in Eclipse with Neon M3 target and > confirmed that there are no compilation errors visible in the IDE. The error logging from the ECJ also is lacking details. I suspect something that the annotation processor is depending on is missing, for I can see the all the relevant bundles present in the classpath. Can you also confirm if they are physically present too? This is first of the two issues. Secondly, why the annotation processing is enabled. Can you please check if -proc:none is part of the arguments that are being passed to the Javac task?
The compiler is a pretty simple java project. Start the ant build in debug mode and check the problem with a debugger.
> Can you also confirm if they are physically present too? I wrote a script to verify that all 117 jars listed on the classpath are present. The script tripped on the following nested jars. org.eclipse.equinox.registry_3.6.100.v20150715-1528/runtime_registry_compatibility.jar com.ibm.icu_54.1.1.v201501272100/icu-data.jar org.eclipse.jdt.debug_3.9.0.v20151020-0755/tools.jar In all three cases, the nested jar in question is not in the bundle, but is referenced on Bundle-Classpath in the manifest, leading PDE Build to add it to the build script. The last one peaked my attention, being a JDT bundle, but it looks like this tools.jar was not present in Mars.1 as well. I am thinking that these are three unrelated bugs.
Another finding... The project that the build is failing on happens to be the first project in the build sequence that PDE Build synthesizes, so I am guessing that some aspect in the entire project set is causing annotation processing to be enabled. I am widening my search.
> Secondly, why the annotation processing is enabled. Can you please check if > -proc:none is part of the arguments that are being passed to the Javac task? I found no project in the set being built that explicitly enables annotation processing. I also did not find any sign of explicit enablement of annotation processing in the root PDE Build invocation. My conclusion is that annotation processing is enabled by default. I then added -proc:none to the compiler args in the root PDE Build invocation. This succeeded in avoiding this issue. My build is working now and I am unblocked. Of course, there is still a bug/regression in here somewhere, but I will leave it for you guys to chase it further as I have no current need for annotation processing.
Here are the bugs that I opened for issues I documented in Comment #19. https://bugs.eclipse.org/bugs/show_bug.cgi?id=481625 https://bugs.eclipse.org/bugs/show_bug.cgi?id=481626 https://bugs.eclipse.org/bugs/show_bug.cgi?id=481627
I hit the same issue while working on Sapphire build. This gave me an opportunity to take another look at this issue. What I am hitting appears to be a PDE bug that was exposed by this JDT compiler change. Basically, the issue is that PDE feature does not require JDT feature. If you start with a base platform and install PDE feature, you get a portion of JDT installed since individual PDE bundles depend on various JDT bundles. This in turns causes PDE Build to to invoke JDT compiler in a way that makes it trip on error documented in this bug. I have opened a separate bug for PDE and I am returning this bug to a resolved state. Bug 481792
(In reply to Konstantin Komissarchik from comment #23) > I have opened a separate bug for PDE and I am returning this bug to a > resolved state. > > Bug 481792 Moving to Verified as per comment 4 and the above comment
