Community
Participate
Working Groups
Build ID: Eclipse 4.1m4 / TM 3.3m4 API Tooling reports an "incomplete build path" on the following projects: /org.eclipse.rse.subsystems.shells.dstore /org.eclipse.rse.subsystems.shells.local /org.eclipse.rse.subsystems.shells.ssh /org.eclipse.rse.subsystems.shells.telnet This is the error reported for each project: Description Resource Path Location Type API analysis aborted for 'org.eclipse.rse.subsystems.shells.dstore' since its build path is incomplete org.eclipse.rse.subsystems.shells.dstore line 0 Fatal Problem The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.core.resources.IProject. Fix the build path then try building this project org.eclipse.rse.subsystems.shells.dstore Unknown Java Problem The type org.eclipse.core.resources.IProject cannot be resolved. It is indirectly referenced from required .class files DStoreServiceCommandShell.java /org.eclipse.rse.subsystems.shells.dstore/src/org/eclipse/rse/internal/subsystems/shells/dstore line 1 Java Problem I've been using Eclipse and API Tooling for years, and haven't seen this error until I upgraded to Eclipse 3.7m3 / 4.1m3. I also don't see the error during our nightly builds -- only in the workspace. The problem goes away when adding an additional.bundles = org.eclipse.core.resources line to the build.properties file. But I don't want to do that, since I see some risk adding core.resources dependencies to my current bundle which would compile fine but then lead to a problem at runtime.
The problem is easy to reproduce by importing the TM team project set into an empty workspace and adding the TM API baseline as described here: http://wiki.eclipse.org/TM/Code_Streams#Indigo_.283.3.29 Here is my understanding of the problem: RemoteCommandShell has a Field of type IProject. LocalServiceCommandShell extends RemoteCommandShell, thus API Tooling wants to see core.resources. o.e.rse.subsystems.shells.core REQUIRES o.e.core.resources RemoteCommandShell { IProject _project; } ServiceCommandShell extends RemoteCommandShell { } o.e.rse.subsystems.shells.local REQUIRES o.e.rse.subsystems.shells.core LocalServiceCommandShell extends ServiceCommandShell { } The o.e.rse.subsystems.shells.local bundle doesn't require o.e.core.resources directly - only indirectly via o.e.rse.subsystems.shells.core . JDT can build with this transitive dependency just fine. But API Tooling seems to require extra setup, where it should find out the transitive dependency automatically.
API tools is only reporting the problem about the build path because it found a JDT build path problem: The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.core.resources.IProject. Fix the build path then try building this project org.eclipse.rse.subsystems.shells.dstore Unknown Java Problem The type org.eclipse.core.resources.IProject cannot be resolved. It is indirectly referenced from required .class files DStoreServiceCommandShell.java /org.eclipse.rse.subsystems.shells.dstore/src/org/eclipse/rse/internal/subsystems/shells/dstore line 1 Java Problem Once you fix the Java problem the API one will go away. We do not do any explicit build path checking, we only look to see if a build path problem has been reported, which in your example, it has.
What bugs me is that the very same workspace didn't have any issues up until Eclipse 3.6, and the nightly builds still build fine. I think that the transitive dependency onto o.e.core.resources should be detected automatically. Since the JDT build path is contributed by PDE in this case, I assume that's a PDE issue?
Workspace build paths are done by PDE/UI
If the workspace build path is incorrect, you shouldn't need api tools to reproduce this. You should have an error marker on the project saying that the build path is incomplete. I just set up your example and that is the case. I believe that your issue is part of bug 73957. The compiler needs the superclass to be available on the build path but PDE doesn't add it because it is not a plug-in dependency (nothing in the manifest).
But it is on the transitive plugin dependency list (A -> B -> C) so I'd expect it to be added on the classpath. Also, my workspace has been building fine for years with older Eclipse's and just started failing with 3.7m3...
try adding the core.resources bundle to the Automated Dependency Management list. That adds it to compile path but not the runtime path. The problem is that JDT (javac in general) has a flat classpath whereas at runtime OSGi has a dynamic delegating classpath. The bundle A that consumes B that consumes C does not need to reference C and JDT/PDE should not add this to the classpath for free as that would be inaccurate. The best option would be for JDT to allow dynamic class lookup but thats a much bigger deal.
(In reply to comment #7) Hi Jeff, I've found out the "Automated Dependency Management" workaround myself, but see the last paragraph of comment 0 for my concerns: When I add core.resources to the classpath manually, I'll be able to compile without error, but the code might not run when the bundle is not available at runtime (eg when C is refactored in a future version to avoid the core.resources dependency). Essentially I'm decoupling compile-time from run-time dependencies, and that looks fishy to me. But perhaps that concern is moot? The main thing I don't grok is why I could compile the same code without error in the past, but with 3.7m3 and later I'm getting the error. - Is B buggy because it exposes a part of C as a protected field's type without reexporting that part of C ? - Is A buggy because it doesn't "Require-Bundle" or "Import-Package" that part of C that's used as a protected field in a parent class (even though it doesn't use that protected field anywhere)?
(In reply to comment #8) > When I add core.resources to the classpath manually, I'll be able to compile > without error, but the code might not run when the bundle is not available at > runtime (eg when C is refactored in a future version to avoid the > core.resources dependency). Not sure how. There is some hierarchy spread across bundles. When you compile the bottom level (I think it was A) the compiler needs to see the entire hierarchy so, in this case, needs to see core.resources. At runtime an individual bundle only needs to see the classes *it* directly references. Loading of indirect dependencies is delegated to whoever has the direct dependencies. Moving things around may require you to update the additional.bundles list but should not break anything as all the direct dependents will either import-package or, if they use require-bundle, will be updated. > The main thing I don't grok is why I could compile the same code without error > in the past, but with 3.7m3 and later I'm getting the error. That is interesting. Not sure what has changed. > - Is B buggy because it exposes a part of C as a protected field's type > without reexporting that part of C ? > - Is A buggy because it doesn't "Require-Bundle" or "Import-Package" that > part of C that's used as a protected field in a parent class (even though > it doesn't use that protected field anywhere)? Neither of these IMHO. B has no choice other than to stop extending C. re-exporting is not the answer as it still forced consumers (A) to require/import. (A) should not depend on C for exactly the reasons you state. It does not even use this code and it would increase coupling unnecessarily.
I just set up all my workspaces from scratch again (ie imported team project sets into empty workspaces), and I can confirm again that this is a regression introducde with Eclipse 3.7m3 -- none of the Eclipse versions before that required setting the additional.bundles. Jeff, you convinced me that the additional.bundles workaround is non-evil so I'm going to apply it, but I'm still surprised by this regression (and could imagine that many others get into a similar situation where their workspace suddenly doesn't build any more after upgrading their host Eclipse).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as wontfix. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
