Community
Participate
Working Groups
I'm a little confused as to how the PDE figures out that a dependency is unused. There are some other bugs related to the PDE reporting false unused dependencies resulting in compile errors - and I suffer from those as well - but this is not the point of this bug. What I am seeing is the following: I have a plugin A providing extension point "pluginA.extension". I also have a plugin B that uses that extension point. Both of these plugins are provided by me, and the extension does not involve any Java code - just declarative stuff. OK, so when I went to add my extension to pluginA.extension, inside my plugin B, I could not see this extension unless I checked "Show only the extension points from the required plugins". I then created the extension and the PDE prompted me to add plugin A to my list of dependencies. OK - makes sense. Now, if I click "Find unused dependencies" on the Dependencies tab of plugin B, it tells me plugin A is unused. But I am clearly consuming an extension point from plugin A, and the PDE put it in my list of dependencies to begin with! So what is going on here? I realize that I do not require plugin A in my classpath for plugin B because there is no Java code between the two. But my plugin B will not function without the pluginA.extension extension point. So it *is* a dependency in my mind - is it not?
I have been working with PDE/plug-ins for a long time but it was not until last year that I was informed about dependencies and extensions. The Manifest.MF defines the bundles necessary to run the code in the bundle itself. PDE presents the dialog to add a dependency to your manifest for a particular extension point for the case where the extension point requires you to implement/extend a class. If you did not add this dependency, the JDT would not provide any help on trying to create/reference/implement/extend the class. So if java code is not required by the extension point, then really it is not needed as a Require-Bundle. In this case, the dependent plug-in is an indirect dependency. OSGi has a similar issue with services. OSGi provides interfaces to define a service which any bundle who users the service will reference. Since the only real dependency is the interface, only that bundle shows up in the dependencies. But when the bundle is launched, it won't do anything unless the implementation of the service is included. So the answer to your question is that as far as the Manifest.MF is concerned, it is an unused dependency. As far as launching the plug-in, it is a dependency.
OK, so what is the recommended behaviour then? Should I always keep track of these runtime dependencies (the ones based on extensions)? I would think so - otherwise you will undoubtedly get into situations where your plugin could be installed, and not work at all. If this is the case, shouldn't the PDE *not* offer to remove these as unused dependencies?
> OK, so what is the recommended behaviour then? Should I always keep track of > these runtime dependencies (the ones based on extensions)? The proper behavior here is to NOT include a java dependency using Require-Bundle on the bundle providing the extension point. We actually do the same thing in org.eclipse.pde when we use an extension point from org.eclipse.ui but do not put a Require-Bundle dependency on it. Unfortunately, it is really up to the developer to make sure the bundle is there in the runtime. To ease this, it is not "invalid" to add the bundle as a Require-Bundle. Just understand that this is not the intent of Require-Bundle as it should be used to provide java classes, hence it really is an unused dependency. By doing this there will probably be an immeasurably small performance slow down as each time a class is loaded since the classpath of the dependent jar will be search unnecessarily.
awesome explanation in comment 1! As you point out, the trick here is that there are many dependencies involved in setting up a running system. Import-Package and Require-Bundle are only part of the story and really only apply to Java classloading. Having an extension to an extension point does not necessarily imply a dependency. For example, we have many cases where a bundle contributes something for use IF the base function is there but the bundle works just fine if the ext pt is not present. In essence what you are seeing is a configuration/provisioning problem. We need a way for a bundle to say "hey, I have an extension point Foo" and for another bundle to say "hey, I *need* an extension point Foo". the plugin.xml covers the first part but the case I point out above makes the current plugin.xml markup insufficient for the dependency spec. It might be interesting to consider adding some markup to extensions so that authors can indicate their intent. If that is the only issue covered by this bug then I suggest moving he bug to Equinox/Bundles for consideration.
Thanks, Jeff (and Brian). I didn't realize that the dependencies were relevant to classloading only. It seems to me that feature dependencies can help with this from a provisioning aspect, but I think people are pushing towards a bundle-only society. ;) One last question though, before we move the bug. In my original bug report I mentioned that the PDE offers to add a plugin as a dependency when you add any extension, if it is not already in the list. I just tested this again, and it does so (at least for me on Eclipse 3.3) whether the extension involves Java code or not (which Brian suggested was not the case in comment #1), and then removes it when you subsequently search for unused dependencies. So, if this is not really a classloading dependency, and the PDE can detect that fact, why does it ask you if you want to add it in the first place? This seems contradictory and is the real reason I filed this - because I was confused as to which behaviour was the recommended or "correct" behaviour.
interesting. when I was reading Brian's comment I thought "hey, they fixed the bug where they auto-add the dependency" :-) guess not. So yes, it does seem like an inconsistency
I don't believe this has ever come up :) I can definitely understand why PDE should not prompt the user when they add an extension that does not have a java attribute. I think we have never checked because we were keeping it simple. The other reason could be performance, as I am not sure how expensive it is to search every element of a schema and all its included schemas for any java attribute. But this does raise a good point, it would be nice if PDE could check to see if the user should add a dependency on the supplier of an extension before prompting the user. If we could do this check with little performance impact, it could help users understand this concept a bit better.
here's a context for the brave
Created attachment 88791 [details] mylyn/context/zip
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.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
