Community
Participate
Working Groups
When we remove an eclipse extension folder from the dropins folder the associated ius get uninstalled but the site still remains in the platform.xml file. This is particularly bad for links since even if we remove the link file from the dropins but leave the contents pointed to by the link intact nothing gets uninstalled.
The first case is handled by bug 229408. The second case is particularly interesting. It means the link file was removed by the location that it pointed to is still around so when we try and reconcile the platform.xml we look and the site still exists so we think it is ok. Essentially we want to remove any sites from the platform.xml file which aren't referenced anymore. This is harder to do with the new story.
Updating the title a little to reflect that we now just have the problem with links.
*** Bug 233449 has been marked as a duplicate of this bug. ***
One thing that I noticed is that when we have a site in the platform.xml that is resulting from a .link file, we do not set the linkFile attribute on the site object. See PlatformConfigurationWrapper#addFeatureEntry and #createSite. Perhaps if we were able to let that attribute filter down, then later on when we are reading the sites in the PlatformXMLListener we would be able to check for the existence of the link file before doing the synchronization.
In the old update manager code, everything is easier because it is all centered around the platform configuration (platform.xml) file and a known location for extension location links files (/links). Essentially when the configuration initializes, it iterates over all the sites and checks to see if the link file still exists and if not, then it unconfigures and removes the site. With p2, we have a profile synchronizer which takes a bunch of repositories (each link file in /links, multiple repositories for repos in /dropins, multiple repositories for other extensions as defined in the platform.xml file, etc) and tries to install as much as it can from all of the repos. That being said, here are my thoughts: - if the linkfile site attribute is already set on a site in the platform.xml file then we are golden... in the profile synchronizer when we are iterating over the sites we can check for this attribute and if it exists check to see if the file exists. if not, then just don't add the repo for that site which would cause things from that site to be uninstalled - so the only case not handled now is the discovery of link files and ensuring the linkFile site attribute is set in the platform.xml file. This is a bit harder since we get the "install feature" command with a table of properties to use during installation. One thing that might work... in the DropinsRepositoryListener when we discover that we have a repo created from a link file, we could set a link file location property on that repo. Then if that property was set on all features which come from that repo, the property could be passed along through the install phase. Then later in the platform configuration wrapper when we create a new site object (because one doesn't exist for our new feature to install) we can add the linkFile site attribute if the property exists. Just an initial thought. I'm not sure if we really want to put that attribute on all the features in the repo but I'm not sure if there is another way to map back from the feature to the repository it came from.
Created attachment 103676 [details] work in progress Here is a work in progress patch. Still doesn't work because when we go to remove the bundle from the configuration (ConfigData#removeBundle) the BundleInfo object that we are trying to remove from the set, isn't #equal to the one in the set. Here is an example of the 2 different bundle info objects with the first one being in the configuration and the second one is the parameter to the #remove method: BundleInfo(org.eclipse.core.resources.spysupport, 1.4.0.200607170928, location=file:C:\Documents and Settings\Administrator\Desktop\eclipse\plugins\org.eclipse.core.resources.spysupport_1.4.0.200607170928.jar, startLevel=4, toBeStarted=false, resolved=true, id=29,no manifest) BundleInfo(org.eclipse.core.resources.spysupport, 1.4.0.200607170928, location=null, startLevel=-1, toBeStarted=false, resolved=false, id=-1,manifest available) I will investigate this further, I just wanted to attach the patch so I wouldn't lose my progress.
I am confused a little if it is the same problem or not... My plugin is integrated with link files also and after I remove link files from dropins, plugins still is started. Even, if I remove entries from platform.xml file and run with -clean property, it still exist. Only, when I remove entries from the "bundles.info" file, my plugin is gone. Eclipse build : I20080530-1730 OS: Mac OS 10.5.2
Yes, this is the same problem.
I should have said re: comment #6 that when in the debugger I hacked the variables so the bundles were actually removed from the configuration and everything was uninstalled as expected.
Not for 3.4. The workaround (although a bit ugly), is to delete the link file, remove/rename the extension location, and start with -clean.
does this need a readme entry or some such?
*** Bug 239427 has been marked as a duplicate of this bug. ***
*** Bug 245458 has been marked as a duplicate of this bug. ***
It also turns out that replacing a bundle in a linked folder with a newer version doesn't get picked up either, at least in 3.5 M1.
I disparately need to fix that because we are using a nightly built plugin and I have to to setup the whole thing with other plugins just to update that ! Can you shed some light on how I can apply this patch to my current ganymede distro ? Which project/subproject to build , what jar to replace , ... Thanks
Michael, your issue is covered by bug 222945. The weird BundleInfo#equals behaviour is covered by bug 246432 and bug 247176. Fix and regression test released to HEAD. Closing.
(In reply to comment #16) > Michael, your issue is covered by bug 222945. > > The weird BundleInfo#equals behaviour is covered by bug 246432 and bug 247176. > > Fix and regression test released to HEAD. > > Closing. > Thanks That's great news. I see that target milestone is 3.5 M3 , Any change that this gonna be applied to ganymede as well ?
Not right now. It is not currently on our list of issues to be addressed in the 3.4.2 maintenance branch.
It is removed from platform.xml, but plugin still is available? Build id: I20081030-1917
Reopen to make sure this gets seen.
Pascal, are you saying that you want this released to 3.4.2?
I talked to Pascal and his intention for re-opening was so the comment on the bug was seen, not so that the fix be released into the maintenance branch. Egidijus, I am unable to reproduce this problem. I did the following: - unzip and start I20081030-1917 build and shutdown - put an extension location in the dropins folder - startup -> notice feature and bundles are installed - shutdown - delete the extension from the dropins folder - startup -> notice feature and bundle are no longer installed - also note that the platform.xml does not contain a site pointing to the dropins folder We also have a regression test for this problem and it has been passing. Please open a new bug report if you have a reproducible problem that we can look into. Thanks.
