Community
Participate
Working Groups
3.3 RC1 - File > Import > Plugins and Fragments - Import As > Projects with source folders - Import org.eclipse.jdt.apt.pluggable.core => 34 compile errors, e.g. "The import org.eclipse.jdt.internal.compiler.apt cannot be resolved" in org.eclipse.jdt.apt.pluggable.core/src/org/eclipse/jdt/internal/apt/pluggable/core/dispatch/IdeAnnotationProcessorManager.java The problem is probably that org.eclipse.jdt.compiler.apt is not a proper plug-in dependency but is just added on the classpath as a Java project.
Unfortunately org.eclipse.jdt.compiler.apt is a fragment rather than a plug-in, so PDE will not let me add it as a plug-in dependency. I will try to find a workaround. Any suggestions?
CCing our PDE wizard. Wassim, do you know of a better way to add the packages from org.eclipse.jdt.apt.pluggable.core's Import-Package: manifest header to the classpath?
The idea here is that since you cannot rely on a fragment being there at runtime (ie. you cannot explicitly make a dependency on it in the manifest), a downstream client or another fragment should not structure their code to get themselves into that situation. More importantly, the Eclipse Supreme Court ruled (bug 45767 comment 31) that the tooling should not be optimized to promote such usage. Plus, if fragment A and fragment B are associated with the same host X, then if you want fragment B to go on fragment A's host then it's only fair for fragment A to go on fragment B's path. Why stop there? technically, both fragments A and B should be on plug-in X's classpath. And you end up in circular classpath hell. That is why PDE promotes the right lifestyle: a fragment gets its host on its classpath. A host does not get its fragments on its classpath. Fragments do not get each other on their classpath. Markus seemed to have found a loophole with his Import-Package suggestion. It may actually work to fool the tooling.
Yes, this is a kind of bizarre case, that pushes the limits of the architecture. The jdt.compiler.apt plug-in is a (Java 1.6 dependent) fragment of jdt.core, because jdt.core needs to load its classes reflectively at runtime, because it can't rely on the extension point mechanism, because it needs to be available in the batch compiler (ecj.jar). But apt.pluggable.core is a regular old plug-in, that extends the base classes defined in jdt.compiler.apt. Like jdt.compiler.apt, apt.pluggable.core requires Java 1.6, so at runtime there's no risk of the fragment not being there. In a sense, apt.pluggable.core is like a fragment of jdt.compiler.apt, but its required EE is the Eclipse platform itself. So, it's ugly. I wonder if maybe the best solution is just to document (in a readme in the plug-in source) that apt.pluggable.core won't build unless the source for jdt.compiler.apt is also in the workspace? Yuck.
Seems like org.eclipse.jdt.core is similar to SWT where additional fragments may supply more API. If that is the case then org.eclipse.jdt.core should add the following header, right Wassim? That fixes the issue in my workspace. Eclipse-ExtensibleAPI: true Note that this header *only* has meaning for PDE-UI. At runtime fragments in integrated with the host and have access to eachother and down stream clients always have access to their content.
oh I missed a vital piece of info in this bug report. jdt.apt.pluggable.core is a plug-in, not a fragment of jdt.core jdt.compiler.apt is a fragment of jdt.core. In which case, then it's simple. Just add Eclipse-ExtensibleAPI: true to the manifest.mf of jdt.core as Tom suggests and you're all set.
Thanks, Tom and Wassim. I'll move this to jdt.core.
I'll provide a patch for it.
It doesn't seem to be that simple. When I add the line Eclipse-ExtensibleAPI: true inside the jdt/core manifest, then I get compile errors for duplicate entry in the classpath for the two projects: org.eclipse.jdt.apt.pluggable.core org.eclipse.jdt.compiler.tool.tests I get the build path errors: Severity and Description Path Resource Location Creation Time Id Build path contains duplicate entry: 'org.eclipse.jdt.compiler.apt' for project 'org.eclipse.jdt.apt.pluggable.core' org.eclipse.jdt.apt.pluggable.core Build path 1180113302769 2131753 Build path contains duplicate entry: 'org.eclipse.jdt.compiler.tool' for project 'org.eclipse.jdt.compiler.tool.tests' org.eclipse.jdt.compiler.tool.tests Build path 1180113302699 2131752 Any clue?
If I have these 4 projects loaded from CVS, everything compiles fine. org.eclipse.jdt.apt.core org.eclipse.jdt.apt.pluggable.core org.eclipse.jdt.compiler.apt org.eclipse.jdt.core I use Import-Package and Export-Package mecanism in order to make some packages defined in org.eclipse.jdt.compiler.apt visible from org.eclipse.jdt.apt.pluggable.core. Could an OSGI/PDE expert tell us what is wrong in the way we defined our plugins/fragments? These plugins/fragments are part of the eclipse builds for weeks now and they build fine. I don't have anything against adding the Extensible-API to true if I can get rid of the build path errors in my configuration. I don't want to break Eclipse build to solve this issue. For now I remove the target milestone as the fix doesn't appear to be that simple.
This is because org.eclipse.jdt.apt.pluggable.core has a strong reference to the org.eclipse.jdt.compiler.apt project in its .classpath. <classpathentry combineaccessrules="false" kind="src" path="/org.eclipse.jdt.compiler.apt"/> This conflicts with the PDE classpath container when it configures the classpath to have org.eclipse.jdt.compiler.apt on the org.eclipse.jdt.apt.pluggable.core project classpath. If possible the PDE classpath container should be the only thing controlling your project's classpath.
Olivier, this needs to be addressed for 3.3. We need to be able to compile without errors of out the box when people import plug-ins with source. 1. Add: Extensible-API: true to the jdt.core manifest. 2. Remove any offending project classpath entry from the .classpath file as Tom suggests. That's it.
Created attachment 68864 [details] Proposed fix
I'll test if the plugins with this patch can be successfully imported when using "Import As > Projects with source folders".
The patch seems to work either when loaded from CVS or import with source folders.
Jérôme, Frédéric and Tom, please review.
+1 for 3.3 RC3. Just make sure you coordinate with JDT/APT when you release this patch so that they contribute at the same time as JDT/Core is contributing.
Of course :-). I'll make the contribution of JDT/APT if needed.
+1 for 3.3 RC3
+1 for 3.3 RC3.
Released for 3.3RC3
+1 for rc3
Olivier and I are in contact regarding APT; he is releasing the APT changes at the same time as JDT, to ensure there are no glitches.
Verified for 3.3RC3 using I20070530-0010.
