Community
Participate
Working Groups
Steps: (1) Have a plugin exporting package org.foo in version x in target platform. (2) Have a plugin exporting package org.foo in version x-1 in workspace. (3) Create a plugin which imports org.foo (without version) and check what plugin dependencies shows. It shows that the new plugin is dependent on plugin in the workspace.
I believe this is intended behaviour. If you have no version constraint, it should not matter which version of a package is used. We give preference to workspace plug-ins over external plug-ins.
This is working as intended.
(In reply to comment #1) > I believe this is intended behaviour. If you have no version constraint, it > should not matter which version of a package is used. We give preference to > workspace plug-ins over external plug-ins. From OSGi perspective this is wrong. If there is no version constraint specified it effectively means the same as version range of 0 to infinity. And at runtime the plug-in that imports the given package will be wired to the plug-in that exports the package with the highest version. Therefore, the build time dependency representation is inconsistent with the runtime dependency representation and that can lead to problems.
Tom, can you confirm that a user can expect OSGi to always take the highest version of a package when there is no version constraint on the dependency? I still feel that PDE's behaviour is reasonable. We always give preference to workspace plug-ins and packages because that is the code you are likely working with.
(In reply to comment #4) > Tom, can you confirm that a user can expect OSGi to always take the highest > version of a package when there is no version constraint on the dependency? At runtime this is correct. > > I still feel that PDE's behaviour is reasonable. We always give preference to > workspace plug-ins and packages because that is the code you are likely working > with. For build time you typically would want to build against the lowest version possible to ensure that you actually can run against the older version. We don't currently do that, but it is perfectly reasonable to compile against the older version of the package if your range states that you can run on that older version.
(In reply to comment #4) > > I still feel that PDE's behaviour is reasonable. We always give preference to > workspace plug-ins and packages because that is the code you are likely working > with. What's the point of giving a preference to a plug-in in local workspace if that plug-in won't be used at runtime? If Eclipse picked the dependency just by following the OSGi rules and it picked one that the user didn't not expect, that could indicate to the user that his/her version constraint might be wrong. But at least in this case the problem is detected at build time and not at runtime.
