Community
Participate
Working Groups
In order to use the annotation processor manager from the org.eclipse.jdt.compiler.apt project inside org.eclipse.jdt.core, we need to add an extension point that will allow the classes from org.eclipse.jdt.compiler.apt to be used inside org.eclipse.jdt.core without having org.eclipse.jdt.code depending on org.eclipse.jdt.compiler.apt.
Created attachment 57937 [details] Proposed fix Zip file that contains the patch.
Walter will add examples and more documentation post M5.
Released for 3.3M5.
I also considered some other possibilities. The basic requirement is that jdt.core needs access to a service in compiler.apt, but cannot be dependent on compiler.apt. This is of course the canonical use case for an extension point. We could use the existing compilationParticipant API as a way of loading the compiler.apt plug-in, and compiler.apt could then register its annotation processor manager with jdt.core through some registration method. But it is not obvious what JDT object should expose the method; and also, this seems circuitous and misleading, since it requires compiler.apt to register an extension that it doesn't actually support. There are also some service bus interfaces supported by OSGi that are somewhat similar to the "META-INF/services" mechanism in Java. However, these all seem to require registration on the part of the callee, which again means that it must extend some sort of extension point in order to wake up and register itself. Eventually, all roads returned to the need for an extension point, and rather than abuse an existing extension point it seems best to create a correct one.
I should also mention why Java 6 annotation processing isn't simply implemented as a CompilationParticipant. The reason is that in order for it to be used in batch mode, it has to run without the Eclipse platform present, so it needs access to the JDT compiler internal typesystem, rather than the Java model. (We also expect this to lead to performance and correctness improvements.) Therefore it runs at a different point in the compilation process, and the definition of the interface is different (e.g., CompilationParticipant depends on IJavaProject).
Verified for 3.3 M5 using build I20070205-0009
