Community
Participate
Working Groups
Steps to reproduce - method A: 0. Unpack some EMF zip into eclipse/dropins/eclipse/emf/ 1. Start up Eclipse 3.4 I20080325-2233 (linux gtk), with Sun 5.0 2. Help > Software Updates... > 3. Select all listed IUs. CTRL-click on the Eclipse SDK IU to remove it. 4. Click Uninstall..., then Finish. 5. Click Close 6. Restart Eclipse. Repeat steps 2-6 until convinced that these features cannot be uninstalled via p2 installer. --- Steps to reproduce - method B (scripted): 0. run this: #!/bin/bash workspace=/tmp/workspace-clean-34 pushd ~/eclipse/34clean >/dev/null if [[ $# -eq 0 ]]; then rm -fr eclipse $workspace eclipse=eclipse-SDK-3.4M5-linux-gtk.tar.gz eclipse=eclipse-SDK-I20080324-1300-linux-gtk.tar.gz eclipse=eclipse-SDK-I20080325-2233-linux-gtk.tar.gz echo "Unpack $eclipse..."; tar xzf $eclipse # echo "Patching org.eclipse.equinox.p2.ui.sdk_0.1.0.v20080317-1820.jar..."; # cp -f org.eclipse.equinox.p2.ui.sdk_0.1.0.v20080317-1820.jar \ eclipse/plugins/; emf=emf-sdo-xsd-SDK-p2break.zip echo "Unpack $emf into eclipse/dropins/emf/" unzip $emf -d eclipse/dropins/emf fi vm=/opt/sun-java2-5.0/bin/java #vm=/opt/ibm-java2-5.0/bin/java echo "Using vm=$vm and workspace=$workspace"; ./eclipse/eclipse \ -vm $vm -data $workspace -consolelog & popd >/dev/null 1. See method A, steps 2-6. --- Steps to reproduce - method C: The same effect can be seen if you use an emf.link file in eclipse/dropins/eclipse/, pointing to some other folder. Install works great. Uninstall does not. $ cat emf.link path=/x/home/nickb/eclipse/34clean/emf-unzipped
*** This bug has been marked as a duplicate of bug 224110 ***
This is expected behavior. The key feature of dropins is that stuff you put in there gets installed automatically on startup. If you uninstall it but don't delete it, it will get re-installed on the next startup. Of course this isn't a good end user experience. Some possibilities: - We could gc (delete) uninstalled bundles from dropins - Disable the "uninstall" action for these IUs (through some property on the IU). - Don't show things from dropins at all in installed features list
I don't think this is a dup
> - Disable the "uninstall" action for these IUs (through some property on the IU). See also bug #215398 and bug #215560. We are going to have a notion of IU's that are locked, because they are the product "base" or they are in a shared install. That would be the way to accomplish this one. Are drop-ins part of the "base"? - Don't show things from dropins at all in installed features list This would mean removing the root IU property (which I believe we just added for M6.) We got bugs when these dropins did not show up, so I don't think this is a good/expected answer. So I would say we either gc them or consider them locked.
> So I would say we either gc them or consider them locked. My $0.02: Lock them -- including some visual indication like a lock icon in a left-most column of the the "Installed Features" dialog table. If I try to use the UI to uninstall them, prompt with either "Link file dropins/foo.link and linked folder /path/to/linked-plugins will be deleted. Are you sure?" - or - "Drop-in folder /path/to/dropins/folder/ will be deleted. Are you sure?" Then, on the next startup, ensure nothing tries to load them (ie., prevent the logged errors/warnings). If you could disable IUs but not delete them, then it gets more complicated (as with deleting a project from the workspace but NOT from the disk). Not sure if we need to get that fancy just yet. ;)
Not sure if this is the same thing or not, but after restarting, I would suspect that the items within the dropins folder would be deleted from eclipse/dropin. Otherwise I'm still just going to end up with a bunch of bloat on my system with outdated plugins and items residing on the system. Maybe I'm misunderstanding the role of the dropin folder in 3.4M6 and P2.
David, I'm note sure to understand what is your use case. To answer your question, in p2 the dropins support provides a best effort of installation and leaves this area untouched (in that it will not perform GC on it) since it is the user who manages it.
Pascal, it was my misunderstanding. I thought the eclipse/dropin folder would act like an installation folder where the items in it would be installed from that folder into the appropriate eclipse/plugins and eclipse/features folder removing and uninstalling anything that was old or not required any longer. However, the dropin folder acts like the old .link files concept instead, except that items are updated or removed only within the dropins folder. Personally I would like to see an option where you have an eclipse/install folder that actually installs updates into a base eclipse system. As it is now, to get the base system to upgrade it requires going through the Software Updates and installing the features through there instead of using the dropins folder in eclipse/dropins for the installation.
Dave, could you please open another bug report where we can carry the discussion about your enhancement. Thx.
Bug 225304 opened for eclipse/install directory enhancement
Susan, I've flagged this as ui although I'm not sure if we also need to do work in the dropin reconciler to flag IUs as locked.
Simon, the ui part of this is already covered in bug #215560. There would be some kind of property that would need to be set to denote the drop-ins as part of the base. So I've renamed this bug accordingly.
We are not planning on doing a lot of investment in the dropins in relation to the UI.
