Community
Participate
Working Groups
Created attachment 117132 [details] patch The org.eclipse.ui.ide bundle has a dependency on the old update manager code for when it builds the contents of the Help -> About -> Configuration Details dialog. It gathers the list of features and plug-ins which are installed in the system. Attached is a patch which removes this dependency and replaces the previous information with the list of InstallableUnits that are in the profile, as well as the bundles which the system knows about.
Created attachment 117139 [details] patch Updated patch. Same as above except that it includes the timestamp of the profile as well.
Why is this code necessary? Is it that the old code wont work anymore or is it simply a matter of us cutting the final strings to the old code?
The old code queries classes in the org.eclipse.update namespace to get the information on the things which are installed. Our goal in the SDK is to get to a point where we can remove the org.eclipse.update bundles from our deliverable, and this is one step towards that.
Okay, that's fair enough. I notice the format/content has changed somewhat. Is this strictly required? I envision a scenario where downstream products use this information in the reporting of their errors and arbitrary changes may break their systems/support processes.
The new content is good, the format changes were gratuitous. In the dialog we would like to see: - the Installable Units installed in the profile - the bundles known to OSGi and their locations on disk How they are presented can be an exercise left to the reader. ;-)
Patch has been applied to HEAD.
I have two questions regarding this: 1) why do we use Import-Package instead of Require-Bundle? 2) are there plans to use API instead code from internal packages?
1). All the cool OSGi people use import-package. 2). Once the p2 provisional API has graduated (for 3.5) there will be non-internal methods to call.
>1). All the cool OSGi people use import-package. Almost all UI plug-ins use Require-Bundle except for ICU where it is needed in order to use the replacement JAR if the ICU bundle is not there. Now starting to more widely use Import-package where Require-Bundle would do might introduce confusion i.e. I think it's better to stick with the existing pattern unless there's a good reason - like for the ICU case.
(In reply to comment #8) > 2). Once the p2 provisional API has graduated (for 3.5) there will be > non-internal methods to call. Could you point me to the open bug for this (with target 3.5)?
(In reply to comment #8) > 1). All the cool OSGi people use import-package. I thought that if we were going to start using import-package we were going to have to start versioning the packages (to get the same level of support for targetting specific bundles). PW
Markus, see bug 248791. Dani, maybe I am confused but I would think that the ICU replacement JAR would easier be switched in if you are using import-package. If you are doing an require-bundle then you would require com.ibm.icu and when you remove it and put com.ibm.icu.base in your system, things would fail to resolve. If you are using import-package then it should all just work. Tom, did you want to comment on the use of import-package vs require-bundle?
>Dani, maybe I am confused but I would think that the ICU replacement JAR would >easier be switched in if you are using import-package. Exactly, that's why we do use import-package for ICU ;-) However, for the other cases there's not such issue and hence we use require-bundle. I only question the newly added import-package statements and not the ICU one.
Ah, gotcha. In that case it was probably just a side effect of how we code on the Core team. In the past we made an effort to go through all our bundles on our team to remove the require-bundle and add import-package instead. So when I submitted the patch, it was just force of habit to only import the packages that I needed. I'm not opposed to changing it back to require-bundle if that is the coding convention on the UI team.
(In reply to comment #11) > I thought that if we were going to start using import-package we were going to > have to start versioning the packages (to get the same level of support for > targetting specific bundles). > > PW > Paul is correct. When importing a package we need to have a version on the exported package so we have some level of control over the version of the package we get. In this case it looks like we are using internals until p2 graduates the code to real API. At that point I would expect the p2 team to put versions on their packages. Once the packages are versioned then I don't see any reason not to use Import-Package. But for now I would use require-bundle to access the p2 internal packages. DJ I assume we will need to supply another patch when the p2 api graduates? Is org.eclipse.ui.ide bundle a friend to p2 right now in order to use the internal packages without warning?
No I didn't add the UI bundle as a friend because I knew we were going to make real API soon. (figured it was only important across releases)
Kim, any objections switching back to required-bundle? AFAIK PDE still has some problems regarding import-package (e.g. for plug-in validation on launch).
(In reply to comment #17) > Kim, any objections switching back to required-bundle? AFAIK PDE still has some > problems regarding import-package (e.g. for plug-in validation on launch). > I've changed it to be dependant on : org.eclipse.equinox.p2.engine;bundle-version="[1.0.100,2.0.0)", org.eclipse.equinox.p2.metadata;bundle-version="[1.0.0,2.0.0)", org.eclipse.equinox.p2.core;bundle-version="[1.0.100,2.0.0)"
Verified by code inspection in I20081209-0100
(In reply to comment #18) > (In reply to comment #17) > > Kim, any objections switching back to required-bundle? AFAIK PDE still has some > > problems regarding import-package (e.g. for plug-in validation on launch). > > > > I've changed it to be dependant on : > > org.eclipse.equinox.p2.engine;bundle-version="[1.0.100,2.0.0)", > org.eclipse.equinox.p2.metadata;bundle-version="[1.0.0,2.0.0)", > org.eclipse.equinox.p2.core;bundle-version="[1.0.100,2.0.0)" Does this mean that the IDE plugin won't work without P2 in 3.5?
(In reply to comment #20) > Does this mean that the IDE plugin won't work without P2 in 3.5? > Correct. But it wouldn't run without update in 3.4 (we've traded the old way for the new way). PW
