Community
Participate
Working Groups
Created attachment 78769 [details] Sample plugin with error. I extracted Eclipse 3.3 GA, Extracted the ClearCase plugin which can be got from: http://www-128.ibm.com/developerworks/rational/library/content/03July/2500/2834/ClearCase/clearcase_plugins.html specifically: http://download.boulder.ibm.com/ibmdl/pub/software/dw/rational/zip/com.r.cc.win32-20061206.zip After launching I created a new 3.2 plugin which depended on the com.rational.clearcase plugin, and used some code inside it. Doing so generated a 'Unable to resolve an indirectly referenced class' error, even though that class was available in the hierarchy of the com.rational.clearcase plugin. I have attached the sample plugin created. It looks like I would need to add all the plugins com.rational.clearcase depended on, as the tooling does not realize it.
Did this used to work in an older release or something? The error sounds valid to me if you have a lot of plug-ins with complex dependencies and you just add one out of nowhere.
If I do this in Eclipse 3.2 it compiled fine without any compile errors.
Sending to UI since it sounds like you are talking about compiling in the workspace.
Yes, this problem is about compile errors being reported in the IDE.
Moving to JDT core to see if they have any in sight.
How many indirectly referenced class errors are you getting? And to which specific types?
Because of this cast expression : (RSCMService) ClearCasePlugin.getCMService() We're resolving the interfaces for RSCMService, which include 2 unavailable interfaces: org.eclipse.core.resources.IResourceDeltaVisitor org.eclipse.core.resources.IResourceChangeListener In 3.3, this additional check was added in the compiler in Expression.checkCastTypesCompatibility() at line 415: tagAsNeedCheckCast(); match = castType.findSuperTypeWithSameErasure(expressionType); // <<<< if (match != null) { return checkUnsafeCast(scope, castType, expressionType, match, true); } The method findSuperTypeWithSameErasure() requires us to traverse all of the interfaces of the castType. The type RSCMService has always implemented the 2 interfaces from org.eclipse.core.resources. Its only with this additional check on the cast expression that the compiler needed to find them. In this case, I think the user will have to add the additional dependency to org.eclipse.core.resources Philippe - any thoughts ?
The two errors are ------------ The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.core.resources.IResourceChangeListener. Fix the build path then try building this project org.sample.core Unknown 1192042730453 8 ------------ The type org.eclipse.core.resources.IResourceChangeListener cannot be resolved. It is indirectly referenced from required .class files org.sample.core/src/org/sample/core Activator.java line 1 1192042730453 9 ------------ If I understand using an example - if my plugin depends on plugin A, and A depends on B and C - I would need to have B and C in my dependencies? That would be too many dependencies, also a change in dependency in B/C would mean both A and my plugin would need to be physically updated.
(In reply to comment #8) > If I understand using an example - if my plugin depends on plugin A, and A > depends on B and C - I would need to have B and C in my dependencies? That > would be too many dependencies, also a change in dependency in B/C would mean > both A and my plugin would need to be physically updated. If A doesn't re-export B and C's public packages/API (in its MANIFEST.MF file), I believe that is how it works at the moment.
My mistake, not necessarily the packages/API, I meant the bundle itself. It's what org.eclipse.ui does, for example. Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.2.0,4.0.0)", org.eclipse.swt;bundle-version="[3.3.0,4.0.0)";visibility:=reexport, org.eclipse.jface;bundle-version="[3.3.0,4.0.0)";visibility:=reexport, org.eclipse.ui.workbench;bundle-version="[3.3.0,4.0.0)";visibility:=reexport, org.eclipse.core.expressions;bundle-version="[3.3.0,4.0.0)"
(In reply to comment #10) Going by this example, if my plugin depended on 'org.eclipse.core.runtime', would I need to add a dependency on 'org.eclipse.core.expressions' also - even though I do not use ANY class inside 'org.eclipse.core.expressions'? > My mistake, not necessarily the packages/API, I meant the bundle itself. It's > what org.eclipse.ui does, for example. > > Require-Bundle: org.eclipse.core.runtime;bundle-version="[3.2.0,4.0.0)", > org.eclipse.swt;bundle-version="[3.3.0,4.0.0)";visibility:=reexport, > org.eclipse.jface;bundle-version="[3.3.0,4.0.0)";visibility:=reexport, > org.eclipse.ui.workbench;bundle-version="[3.3.0,4.0.0)";visibility:=reexport, > org.eclipse.core.expressions;bundle-version="[3.3.0,4.0.0)" >
(In reply to comment #11) > Going by this example, if my plugin depended on 'org.eclipse.core.runtime', > would I need to add a dependency on 'org.eclipse.core.expressions' also - even > though I do not use ANY class inside 'org.eclipse.core.expressions'? That example doesn't really work because core.runtime doesn't depend on core.expressions. Let's say I add o.e.core.resources as a dependency. Notice that this bundle does _not_ reexport any other bundles it originally requires. I make a class and make a private field of type org.eclipse.core.resources.IFile, no problems there, everyone's happy. But once I try to do anything with the field, code completion gives me nothing. If I try file.getAdapter(null);, it'll give me two errors. ----- The project was not built since its build path is incomplete. Cannot find the class file for org.eclipse.core.runtime.IAdaptable. Fix the build path then try building this project The type org.eclipse.core.runtime.IAdaptable cannot be resolved. It is indirectly referenced from required .class files ----- Now if I add a dependency to o.e.core.runtime, my compiler errors will disappear. As to your question, you _are_ using those classes _indirectly_. In my example, sure, I'm directly calling IAdaptable's interface method getAdapter(Class), but I think you see what I am trying to get at here.
So do we have agreement that the user needs to add the additional dependency in this case? If so, I'll close this PR.
Yes, I understand what the problem with the CC plugin is - they have provided API whose dependencies were not re-exported. Even though I was using purely CC api, I was inadvertently (becuase it implemented) using another plugin which was not in my dependencies. As a best practice plugin providers should re-export all plugins which are being used for API. Maybe the tooling could warn of this in future. You can close the defect please. Thanks.
Yes taking advantage of the 're-export' option would solve this problem.
Verified by user
