Community
Participate
Working Groups
Build Identifier: M20110909-1335 I detected a severe inconsistency in updating installed plugins that have been installed by simply dropping its contents of "features" and "plugins" in the corresponding Eclipse folders. When you do this you are able to update / install a different product which would have been identified as incompatible when using the normal update manager dialog. Reproducible: Always Steps to Reproduce: 1. Prepare a raw installation of Eclipse. 2. Dropin the folders "features" and "plugins" that you get from the plugin "EMF - Eclipse Modeling Framework SDK" ("org.eclipse.emf.sdk.feature.group") in version 2.7.0.v20110606-0949. 3. Start Eclipse and try to update the plugin "Source for EMF - Eclipse Modeling Framework Runtime and Tools" ("org.eclipse.emf.source.feature.group") to version 2.7.1.v20110913-1526 and you will succeed. Repeat the steps now by installing "EMF - Eclipse Modeling Framework SDK" in step 2 from the update manager. Then you will fail to update "Source for EMF - Eclipse Modeling Framework Runtime and Tools". One of the two behaviour patterns is incorrect, isn't it?
At one point if you installed something via the drop-ins, then we didn't allow you to update it via the UI. Will have to check the code to see what happens now. And that, my friends, is why installing through the drop-ins (where everything is installed optionally) is not encouraged. :)
(In reply to comment #0) > 3. Start Eclipse and try to update the plugin "Source for EMF - Eclipse > Modeling Framework Runtime and Tools" ("org.eclipse.emf.source.feature.group") > to version 2.7.1.v20110913-1526 and you will succeed. > Is this done through the UI?
Yes. This step is done through the UI.
... and update site was "http://download.eclipse.org/releases/indigo".
Oops. I mis-read your original post. The results you see are expected. That's the difference between installing via the UI and installing through the drop-ins folder. When you use the drop-ins to install something, everything you try to install is considered optional. Consider your scenario in which EMF SDK requires EMF Source. In the first case you have EMF installed (optionally) so when you want to install a higher version of the source, then that is allowed. Things installed via the UI are given higher priority so the source is installed and certain items in the drop-ins, whose dependencies are no longer satisfied, are actually uninstalled since everything is considered to be optional anyways. This will result in you having most of the pieces of EMF still installed, but the top level piece of metadata (InstallableUnit - IU) that points to everything will not be installed. In the second case you are installing everything through the UI so you start with the SDK and Source features installed. The SDK has a hard dependency on a specific version of the Source so when you try and replace that by installing a new version, p2 won't let you because it would break the dependency of what you already have installed.
OK. You're perfectly right:-) Indeed the SDK got uninstalled after an update of the sources project in scenario 1. Thanks for your explanation! I finally understood that.
Let me notice just some ideas for optimzation on the general dropins behaviour: The problem of the dropin mechanism is that I regularly do not wish anything to get entirely uninstalled implicitly especially because the updated plugin is given the higher priority now and is not optional anymore (even when its files are coming from the dropinis folder). It would be much better to get informed about what plugins become uninstalled when you make an update / installation of a plugin with an option to proceed and an option to return to selection dialog to modify your choice (e.g. select a different version of / uncheck a plugin). In my example it would have been nice that I would have got a notification about the upcoming uninstallation of EMF SDK when I was trying to update the EMF sources. Additionally it seems to be necessary to me being able to mark single installed / to be installed plugins as optional on the one hand and fixed / permanent on the other hand (at least for items from the dropins folder). Then it would be quite handy to drop new plugins in the dropins folder without the risk to shoot necessary parts of your installation. As long as these suggestions are not being implemented the dropins folder indeed is barely feasible compared to use the perpared folders with the plugins (originally destined for the dropins folder) as a local software site and install the plugins through the UI. That's the way I'll do it now. Again thanks for your prompt assistance.
