Community
Participate
Working Groups
I20111108-1014 To work around bug 305642, I have a script that loads the latest version of EGit and JGit plug-ins into a shared folder that I include through a links/egit.link file. I use the same linked folder from all my Eclipse installs (similar to using dropins, but without the overhead). Recently, I often get into trouble when I have multiple versions of egit and jgit plug-ins in the linked folder. I always start up with -clean, and I would expect that the latest version of each plug-in is chosen when there are no other constraints. Unfortunately, that's not always the case. Currently, I have several versions of all the egit/jgit plug-ins in the shared folder. The bundles.info looks like this: [..] org.eclipse.egit.core,1.2.0.201111110427,../../extensions-p2/egit/eclipse/plugins/org.eclipse.egit.core_1.2.0.201111110427.jar,4,false org.eclipse.egit.doc,1.2.0.201111110427,../../extensions-p2/egit/eclipse/plugins/org.eclipse.egit.doc_1.2.0.201111110427.jar,4,false org.eclipse.egit.ui,1.2.0.201111110427,../../extensions-p2/egit/eclipse/plugins/org.eclipse.egit.ui_1.2.0.201111110427.jar,4,false [..] org.eclipse.jgit,1.2.0.201111070410,../../extensions-p2/egit/eclipse/plugins/org.eclipse.jgit_1.2.0.201111070410.jar,4,false org.eclipse.jgit,1.2.0.201111090410,../../extensions-p2/egit/eclipse/plugins/org.eclipse.jgit_1.2.0.201111090410.jar,4,false org.eclipse.jgit,1.2.0.201111110411,../../extensions-p2/egit/eclipse/plugins/org.eclipse.jgit_1.2.0.201111110411.jar,4,false [..] I guess the EGit plug-ins are only there once because they are singletons. JGit is not a singleton. At run time, the Plug-in Registry looks like this: [..] org.eclipse.egit.core (1.2.0.201111110427) "Git Team Provider Core" [Active] org.eclipse.egit.doc (1.2.0.201111110427) "Git Team Provider Documentation" [Resolved] org.eclipse.egit.ui (1.2.0.201111110427) "Git Team Provider UI" [Active] [..] org.eclipse.jgit (1.2.0.201111070410) "JGit Core" [Active] org.eclipse.jgit (1.2.0.201111090410) "JGit Core" [Starting] org.eclipse.jgit (1.2.0.201111110411) "JGit Core" [Starting] [..] => Wrong JGit plug-in is active.
DJ, is p2 expected to only allow a single version of the non-singleton bundle to be installed?
Nope, we should allow it. Sorry I mis-read the bug and thought that we had installed the wrong things. But it sounds like we are installing the right things but the wrong ones are being wired. Moving back to the framework.
The problem is that the bundles.info gets sorted alphabetically, and Equinox always loads the first matching bundle from that list. When we reorder the org.eclipse.jgit entries in the bundles.info to have the latest version on top, then that one gets activated at run time. So the fix could either be to reorder the bundles.info with the latest version on top, or to make Equinox load the last matching bundle from bundles.info (or even better: the latest matching version).
I'm not sure how things are wired to jgit, but if they are using import package then I suspect we are picking the first bundle installed that provides the package since I suspect their package versions to all be the same for the different versions you have installed. If multiple exported packages (with the same package name and version) are available then we split the tie by picking the first provider bundle installed.
(In reply to comment #4) > I'm not sure how things are wired to jgit, but if they are using import > package then I suspect we are picking the first bundle installed that > provides the package since I suspect their package versions to all be the > same for the different versions you have installed. If multiple exported > packages (with the same package name and version) are available then we > split the tie by picking the first provider bundle installed. I didn't see any split package but export and import package are used like this: Export-Package: org.eclipse.jgit.util;version="2.3.0", and in client bundle: Import-Package: org.eclipse.jgit.util;version="[2.3.0,2.4.0)", IMHO the real problem is like Markus said: 1. the file is sorted alphabetically ==> newer ones come later 2. the first bundle from the file is picked as you say ==> we always get the older one
(In reply to comment #5) > (In reply to comment #4) > > I'm not sure how things are wired to jgit, but if they are using import > > package then I suspect we are picking the first bundle installed that > > provides the package since I suspect their package versions to all be the > > same for the different versions you have installed. If multiple exported > > packages (with the same package name and version) are available then we > > split the tie by picking the first provider bundle installed. > > I didn't see any split package but export and import package are used like > this: Split was a bad term to use. I should have stated we BREAK the tie by picking the first provider bundle installed. > > Export-Package: org.eclipse.jgit.util;version="2.3.0", > and in client bundle: > Import-Package: org.eclipse.jgit.util;version="[2.3.0,2.4.0)", > > IMHO the real problem is like Markus said: > 1. the file is sorted alphabetically ==> newer ones come later > 2. the first bundle from the file is picked as you say > ==> we always get the older one I think we are in agreement on the cause, but I am not sure p2 should be enforcing an install order to work around this issue. IMHO if you don't want the older versions to be used then you should have a configuration that does not install the older versions.
(In reply to comment #6) > I think we are in agreement on the cause, but I am not sure p2 should be > enforcing an install order to work around this issue. IMHO if you don't > want the older versions to be used then you should have a configuration that > does not install the older versions. Sorry, I do not understand what you try to say. As a user I install a newer version from the update site. p2 then orders the bundle info file and later loads the older version. So, what do you mean by "you should have..."? ;-)
Having multiple bundles with differing versions installed is a normal mode of operation. In this bug's case, the bundles only differ in the qualifier. The ordering of the qualifiers is well-defined, and the reasonable resolution is to use the latest one. > we split the tie by picking the first provider bundle installed. That doesn't sound right, given that OSGi knows about bundle versions and their ordering. But if that's OSGi's take, then the only open question is who owns the bundles.info file and whether the writer or the reader has to sort it.
(In reply to comment #8) > Having multiple bundles with differing versions installed is a normal mode > of operation. In this bug's case, the bundles only differ in the qualifier. > The ordering of the qualifiers is well-defined, and the reasonable > resolution is to use the latest one. > > > we split the tie by picking the first provider bundle installed. > > That doesn't sound right, given that OSGi knows about bundle versions and > their ordering. But if that's OSGi's take, then the only open question is > who owns the bundles.info file and whether the writer or the reader has to > sort it. But in this case the package versions are identical so from the resolver's point of view the two packages are identical. When selecting a package provider for an Import-Package we do not look at the bundle version. p2 owns the order of the bundles.info. (In reply to comment #7) > (In reply to comment #6) > > I think we are in agreement on the cause, but I am not sure p2 should be > > enforcing an install order to work around this issue. IMHO if you don't > > want the older versions to be used then you should have a configuration that > > does not install the older versions. > > Sorry, I do not understand what you try to say. As a user I install a newer > version from the update site. p2 then orders the bundle info file and later > loads the older version. So, what do you mean by "you should have..."? ;-) I thought this scenario was about setting up a links folder and which is not really managed properly by p2. It seemed like you were just adding stuff to a folder and then configuring in the links folder which is basically enabling a dropins folder IIRC. So I did not view this as a normal user going to an update site and doing normal installs and or upgrades.
(In reply to comment #9) > But in this case the package versions are identical so from the resolver's > point of view the two packages are identical. What's the point of the qualifier then? > I thought this scenario was about setting up a links folder and which is not > really managed properly by p2. It seemed like you were just adding stuff to > a folder and then configuring in the links folder which is basically > enabling a dropins folder IIRC. So I did not view this as a normal user > going to an update site and doing normal installs and or upgrades. No, this happened during normal update of nightly EGit builds.
(In reply to comment #10) > (In reply to comment #9) > > But in this case the package versions are identical so from the resolver's > > point of view the two packages are identical. > > What's the point of the qualifier then? That is just the bundle version. Nothing prevents a package version from being decremented in an updated bundle. Package versions are not related to the bundle version they happen to be exported from. If we want bundle qualifiers to apply to package versions then we need support from the build to automatically add a qualifier to the package versions exported from a bundle. > > > > I thought this scenario was about setting up a links folder and which is not > > really managed properly by p2. It seemed like you were just adding stuff to > > a folder and then configuring in the links folder which is basically > > enabling a dropins folder IIRC. So I did not view this as a normal user > > going to an update site and doing normal installs and or upgrades. > > No, this happened during normal update of nightly EGit builds. This seems wrong to me from a p2 point of view. If p2 is doing an update from a repo to a new version then I don't understand why p2 is not uninstalling the old versions. Ian, can you comment?
> I thought this scenario was about setting up a links folder and which is not > really managed properly by p2. It seemed like you were just adding stuff to > a folder and then configuring in the links folder which is basically > enabling a dropins folder IIRC. So I did not view this as a normal user > going to an update site and doing normal installs and or upgrades. Yes, that's my scenario (comment 0). Dani also thought he had seen this problem using just the p2 UI. But we verified now that p2 indeed removes the old JGit bundle from bundles.info (but also keeps the old JAR in the plugins folder). So this problem only occurs with a dropins or linked folder. Moving this bug to p2. p2 should make sure that the latest version of a singleton bundle is loaded. (In reply to comment #4) > If multiple exported > packages (with the same package name and version) are available then we > split the tie by picking the first provider bundle installed. There are two ways p2 could fix this bug: (a) when adding a bundle to the bundles.info, insert it at the right position (b) when installing the bundles from bundles.info, make sure the latest version of each bundle is installed first (i.e. don't respect order in bundles.info) I think (a) is the better solution.
> There are two ways p2 could fix this bug: > (a) when adding a bundle to the bundles.info, insert it at the right position Is the right position, the most recent version installed into the system (which may be an older version), or sort the bundles.info by the entries by BSN and decreasing version order?
The right order is by BSN and decreasing version order (since Equinox will use the first installed bundle if there are no other constraints, and the user more likely prefers the latest order). If you expect someone outside of p2 to also touch the bundles.info file, then there's a possibility that the bundles.info is not properly ordered when you read it. If you think that these external modifications are worth keeping, then it gets a bit more complicated: In that case, you would have to do the analysis at the point where a bundle gets added to the bundles.info and use some heuristics to decide where to put it (e.g. in front of the first entry with matching BSN but lower version). But I don't think that's necessary.
Created attachment 225393 [details] Fix
Patch released. Thx.
Verified in N20130120-2000.
