Community
Participate
Working Groups
In order to find out about installed bundles JDT uses provisional p2 API. We would like to request that those parts become official API for 3.6 or that we get something along these lines: /** * Finds the bundle info for the given arguments. * <p> * The first match will be returned if more than one bundle matches the arguments. * </p> * * @param symbolicName the symbolic name * @param versionRange the version range for the bundle version * @param isSourceBundle <code>true</code> if it is a source bundle <code>false</code> otherwise * @return the bundle info or <code>null</code> if not found */ public static BundleInfo findBundle(String symbolicName, VersionRange versionRange, boolean isSourceBundle) {
*poke* Can we look at this one early in 3.6 guys? This has been causing some strain in the PDE and JDT teams (see bug 283011)
Marking as 3.6 so it remains on the radar.
Can we get this early in the cycle to make sure it fits our needs?
Bug 243242 was where the original changes for SimpleConfiguratorManipulator were defined. I have marked that bug fixed as the patch there was released in 3.5. One outstanding question that was left there was the use of URL (and to a lesser extent File) in the method signature. p2 has moved to URIs, perhaps this URL needs to be changed.
Andrew, I'm not quite sure how to interpret your previous comment. Are you saying this is already possible via API? If so, can you point us there? The patch you mentioned adds internal/provisional API and not API.
There is no official API yet. That patch just created the provisional API that we are proposing to make real. Before that patch there wasn't anything even close to API. Though, re-reading comment #0, is that provisional SimpleConfiguratorManipulator enough? You would need to find the bundles.info yourself and search the resulting BundleInfo[].
Yes, for us it would be enough. You can take a look at Plug-in: org.eclipse.jdt.junit org.eclipse.jdt.internal.junit.buildpath.P2Utils org.eclipse.jdt.internal.junit.buildpath.BuildPathSupport to see which provisional code we use.
This is the API request from JDT/UI, as asked for in http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg03703.html .
Any progress here? I don't want to waste time reviewing and testing patches like bug 297663.
I'll start looking at this. Some initial comments, 1) re bug 297663, the "launcherLocation" for SimpleConfiguratorManipulator#loadConfiguration is the location to resolve relative URIs against, I don't see how P2Utils.readBundle with useConfigArea==true can ever be the right thing to do. When would we ever expect there to be bundles located in eclipse/configuration/plugins/* ? 2) BundleInfo - We should remove some of those constructors - BundleInfo#get/setManifest : what are these for? - I wonder if we should add a get/set User Object (like BundleDescription) - get/setVersion - should this remain as a string? Is it better as a org.osgi.framework.Version ? 3) SimpleConfiguratorManipulator - should this be named ISimpleConfiguratorManipulator ? - load/saveConfiguration: URL url & File outputFile refer to the bundles.info file we are loading/saving. Maybe these should both perhaps be replaced by InputStream/OutputStream? - loadConfiguration: "launcherLocation" doesn't seem like a good name here. This should also be a URI instead of a file. - saveConfiguration: base should be a URI - extends ConfiguratorManipulator, this will pull in Manipulator BundlesState ConfigData LauncherData FrameworkAdminRuntimeException Do we really want all of this as API? Perhaps some should be spi instead, it all needs reviewing. If we remove the extends ConfiguratorManipulator we can graduate SimpleConfiguratorManipulator without the rest.
(In reply to comment #10) > 1) re bug 297663, the "launcherLocation" for > SimpleConfiguratorManipulator#loadConfiguration is the location to resolve > relative URIs against, I don't see how P2Utils.readBundle with > useConfigArea==true can ever be the right thing to do. When would we ever > expect there to be bundles located in eclipse/configuration/plugins/* ? For me at least, calling P2Utils.readBundle with useConfigArea==true has the following behavior, which seems reasonable to me: 1. Reads ~/.eclipse/155965261/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info 2. Resolves relative URLs from above bundles.info to a base of ~/.eclipse/155965261, which does contain plugins I have installed that are not a part of the shared install. The problem I am trying to address with bug 297663 is that reading bundles.info from the configuration area should not be strictly tied to resolving relative URLs to the configuration area. It should still be possible to resolve them to the shared install area.
>Do we really want all of this as API? See comment 0 for what JDT UI needs (can't speak for others). This should find the bundle no matter whether it is in the official install, dropins or other location. Optionally you could add a parameter to tell to restrict the search to dropins and/or install and/or other locations, but we (JDT UI) don't need this. Regarding bug 297663: we have to backport the fix to 3.5.2 so it would be appreciated if you can tell us the correct way to fix the current code so we can achieve the functionality requested in comment 0 based on 3.5. Of course best would be to backport your new API ;-).
(In reply to comment #11) > 1. Reads > ~/.eclipse/155965261/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info > > 2. Resolves relative URLs from above bundles.info to a base of > ~/.eclipse/155965261, which does contain plugins I have installed that are not > a part of the shared install. Looking at P2Utils.readBundles, I don't see how we get this. I'm not sure how a shared install changes things, I will need to talk to some of the others. I don't believe there are 2 cases (useConfigArea) for base, as far as I can see, the code that is loading the bundles.info to actually start eclipse is resolving against osgi.install.area (Location.INSTALL_FILTER). (In reply to comment #12) > >Do we really want all of this as API? > See comment 0 for what JDT UI needs (can't speak for others). This should find > the bundle no matter whether it is in the official install, dropins or other > location. Optionally you could add a parameter to tell to restrict the search > to dropins and/or install and/or other locations, but we (JDT UI) don't need > this. I was looking more at comment #6 & 7. A find method that can deal with source bundles is a much higher level thing and doesn't go here. I think it goes somewhere around the EclipseTouchpoint
(In reply to comment #13) > Looking at P2Utils.readBundles, I don't see how we get this. I'm not sure how > a shared install changes things, I will need to talk to some of the others. > I don't believe there are 2 cases (useConfigArea) for base, as far as I can > see, the code that is loading the bundles.info to actually start eclipse is > resolving against osgi.install.area (Location.INSTALL_FILTER). You may be right about this. I have only tried to resolve plugins that are installed in osgi.install.area with the P2Utils code. However, when I install plugins into my personal area using the software update feature, they go into ~/.eclipse/155965261/plugins I have created another version of my patch for bug 297663 that fixes this problem and gets rid of useConfigArea. I've also attached the modified version of P2Utils.java so that you can review the change directly. I hope it can be of some use in creating the official API for this.
(In reply to comment #14) > I have created another version of my patch for bug 297663 that fixes this > problem and gets rid of useConfigArea. I've also attached the modified version > of P2Utils.java so that you can review the change directly. I updated my patch for bug 297663 again because the previous version did not check the install location for plugins. I think this version is easier to understand and more correct than the original P2Utils as shipped in version 3.5.1.
Created attachment 160555 [details] current patch
Created attachment 160707 [details] patch to p2 & pde.build
Created attachment 160708 [details] patch to jdt junit
Created attachment 160710 [details] patch to pde
Curtis, Dani, Markus, can you please take a look at the JDT & PDE sides of this change. It would be nice to get this in Wednesday if possible.
The PDE patch is fine, ready to commit. Are we putting in the changes today?
(In reply to comment #21) > The PDE patch is fine, ready to commit. Are we putting in the changes today? We need a response from JDT first.
Looks good, but I could not really test it in the wild due to bug 304669. API problems: - The new BundleInfo needs Javadoc. E.g. the format of getVersion must be specified (a valid argument for the org.osgi.framework.Version.Version(String)). You also have to specify which properties can be null (and make sure the others are never null). - The Javadoc of SimpleConfiguratorManipulator has bugs and is incomplete. Please enable more checks in Java Compiler > Javadoc. E.g. "@param bundleInfoPath:" is wrong (there must be a space after the parameter name, and the colon should be removed). The loadConfiguration methods are missing @return descriptions. The API should specify that the returned BundleInfo objects are fully resolved, so e.g. their getVersion() methods always return a version. Compile errors with the patches: - org.eclipse.pde.build's manifest misses update of Import-Package: org.eclipse.equinox.internal.simpleconfigurator.manipulator ('provisional' removed) - org.eclipse.pde.api.tools.ui also declares Require-Bundle: org.eclipse.equinox.frameworkadmin;bundle-version="[1.0.100,2.0.0)" => version also needs to be increased in that plug-in I'm ready to release the JUnit patch for N20100304-2000.
Looking closer at the patch, I realized that we're still missing API that tells us the location of the source.info and bundles.info files in org.eclipse.jdt.internal.junit.buildpath.P2Utils: SRC_INFO_PATH, BUNDLE_INFO_PATH.
Created attachment 160958 [details] update jdt patch Updated JDT patch. Note in particular passing null to loadConfiguration(BundleContext, String) to get the bundles.info for the running system
Created attachment 160959 [details] updated p2 & build Updated patch with javadoc and small changes to BundleInfo
Created attachment 160960 [details] updated pde Updated PDE patch
Created attachment 160963 [details] api tools manifest patch Patch to update api.tools.ui manifest with new version range
Created attachment 160970 [details] Updated JDT Updated jdt patch with suggestion from Markus to define a SOURCE_INFO, if loadConfiguration(BundleContext, String) has string == SOURCE_INFO, we load the default source info, which today is just SOURCE_INFO_PATH but could conceivably change in the future.
Created attachment 160971 [details] update p2 / build change for the SOURCE_INFO
(In reply to comment #28) > Created an attachment (id=160963) [details] > api tools manifest patch > Patch to update api.tools.ui manifest with new version range Committed.
p2 & PDE/Build changes are released. Olivier released the api tools patch. Markus is doing JDT & Curtis is doing PDE. We will be tagging this for the warmup build.
