Bug 332507

Comment 1 Martin Oberhuber 2010-12-14 05:30:15 EST

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.

Comment 2 Michael Rennie 2010-12-14 09:59:52 EST

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.

Comment 3 Martin Oberhuber 2010-12-14 10:27:10 EST

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?

Comment 4 Andrew Niefer 2010-12-14 10:43:28 EST

Workspace build paths are done by PDE/UI

Comment 5 Curtis Windatt 2010-12-15 16:01:23 EST

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).

Comment 6 Martin Oberhuber 2010-12-15 18:05:24 EST

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...

Comment 7 Jeff McAffer 2010-12-15 20:00:55 EST

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.

Comment 8 Martin Oberhuber 2010-12-16 00:38:14 EST

(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)?

Comment 9 Jeff McAffer 2010-12-16 10:23:05 EST

(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.

Comment 10 Martin Oberhuber 2011-01-03 12:49:03 EST

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).

Comment 11 Eclipse Genie 2019-03-21 20:08:23 EDT

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.

Comment 12 Lars Vogel 2019-10-08 10:47:19 EDT

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.