Community
Participate
Working Groups
If we want to develop with an eclipse that have been provisioned with p2, we need a target provisioner that shapes the target based on the bundles.txt.
seems like something for the p2 pde support?
bundles.txt == platform.xml?
Darin, tell your boys to look into this (or we can at the Summit). If they can read a txt file and return an array of File objects, they're good :) IProvisionerWizard is of interest here. I'm attaching a Mylyn context for people that love Mylyn.
Created attachment 79042 [details] mylyn/context/zip
Jeff, direction from the provisioning team like what APIs to use would be fantastic.
I don't think there is API for this right now. See SimpleConfiguratorUtils.readConfiguration in bundle org.eclipse.equinox.simpleconfigurator.
I have released an initial implementation in a project called org.eclipse.equinox.p2.target (under equinox-incubator/provisioning). It does not work because PDE is trying to be smart and does not use the File provided by the wizard as is, but it actually looks in a subfolder of the given file.
CC'ing Brian for input.
Darin is going to take a look at this when he gets some time in the near future.
Is there anything happening on that front?
Jeff, Curtis and I are meeting tomorrow afternoon re: p2 tooling.
I'm reiterating my request on this bug. This is fairly important to us for selfhosting.
Wiki page describing evolution of this (and other PDE related) p2 features is at http://wiki.eclipse.org/Equinox_p2_PDE_Integration#Target_Provisioning
As part of this work, you need to consider refactoring out Update related code into another plug-in in PDE. This way when the time comes, it will be easier to drop support for features. Plus, the goal of componentizing PDE better is always nice.
Status update: The IProvisionerWizard interface, implemented by clients such as the p2 target provisioner is required to return a collection of files representing directories that contain plug-ins to be added to the target platform. For p2, we'd prefer to return a collection of files representing the plug-ins (bundles) themselves. However, as pointed out in bug 207503, this means it is not easy tell the difference between a plug-in in a folder and a folder containing nested plug-ins. Since p2 could suppport a configuration where plug-ins are distributed in many folders, but only a few plug-ins are taken from each folder, I propose that an immediate solution would be to have the p2 provisioning wizard return a collection of folders containing plug-ins (as per the original spec), but in addition allow for an IProvisionerWizard2 interface specifying the set of enabled plug-ins from those directories. This way it will be easier to manage/automatically set the collection of enabled plug-ins. In the longer term, I think we need to look at more flexible APIs/models for supporting multiple target definitions in the workspace. However the immediate goal is to enable p2, rather than to expose all of its power.
Created attachment 82330 [details] Patch for equinox.p2.target Alternative solution. This patch modifies the p2 target bundle to use it's own UI elements rather than trying to integrate with PDE's preference page and extension point. Target provisioning is accomplished by creating a 'target definition' file that describes the folders where bundles can be found and which bundles to include in the target. This patch provides a new main menu entry that allows target definitions to be managed. There is an option that will use a wizard to create a definition file from a p2 install directory. After creating it, the target described by the file can be loaded as the target platform in several ways 1) A 'load' entry under the new menu, 2) The 'Load as Target Platform' link in the target definition editor, 3) On the target platform preference page, browsing to your file and pressing load. Known issues: - You must create the definition file in your workspace (so you must have a project to put it in). - The target platform preference page will still add every bundle in every directory referred to in the bundles.txt to the target, but only the specified bundles will be enabled. Changing this will require significant changes to PDE. - The code uses a lot of internal PDE code, could probably be optimized and needs more documentation.
This bug can probably be closed, as we are taking other approaches to integrating p2 with PDE, but I'll let Darin decide. Removing dependency on bug 207503 because we don't need any changes to IProvisionerWizard.
This will be worked on for M5. We are going to replace the current update site provisioner with one that supports both p2 and old update sites. The UI will reuse components already available in p2 to browse repositories, select groups/features, download the associated artifacts/bundles and add them to the platform. We will try to use PDE's existing API/extension point, though it only allows directories to be returned. The p2/PDE integration wiki page has been updated at http://wiki.eclipse.org/Equinox_p2_PDE_Integration
Darin, should this bug be moved to the PDE bucket?
The actual code changes will be part of p2, using the extension point provided by PDE, so this is not a PDE bug.
Can this be closed?
We still plan on enhancing the the target plaform pref page to allow downloading from a p2 site (similar to downloading from an update site). Should be moved to PDE.
FYI, this should be a p2 bug not a PDE bug. They should have ownership of the extension IMHO. Let's try this for M7.
how about we stop moving it around and just implement the function. I assume that Curtis or Darin is doing the work... I agree with having the p2 tooling distinct from the main body of pde code but it is not clear that the bundles should not have pde in the name. Lets get the function and worry about naming the bundle later. Can someone take ownership of this
Curtis will work on this in M7.
I am getting close to having a patch ready, but I need to know where it is going. I'm using enough p2 UI code that it should really belong to Equinox p2, not PDE. However, it will have to be in a plugin that depends on PDE to access the extension point. Currently I am working in the org.eclipse.equinox.p2.target plugin, which is part of the incubator. Can someone from p2 comment on where the code should go?
I'm fine as it being a separate plug-in. I would actually love to move the Update target provisioner in another plug-in also. We can use this as an opportunity to do both.
As I'm not sure to know what are you after, here are 3 answers to the question - committer ownership? Curtis :-) - bugzilla component? PDE - feature inclusion? PDE because of the dependency on the PDE extension. - plugin name? I'm with the current name As for moving the update target into a separate plugin, I don't see the immediate value since that will not remove the dependency that PDE has on update anyway, but I'm not the owner.
The target provisioner requires PDE and p2. PDE will own the code. I propose to make a new plug-in called something like "org.eclipse.pde.ui.p2". This will allow us to keep the new function under the PDE umbrella but still separated from PDE proper. This gives us flexibility when producing nob-p2-ized builds, etc. In the future PDE will likely depend on p2 directly, but we don't want to make the hard dependency yet.
Created attachment 94728 [details] Screenshot of provisioner Attached is a screenshot showing what my current work looks like. You can select a directory to download bundles to (default is a new directory inside the pde.core metadata (the same place runtime configuration data is stored). There is an option to clear the folder before downloading (because any bundles in the folder will end up in your target). The UI to select an IU is based on provisional p2 API. I had to hack a few things in to get the site management and properties buttons to work properly. When you hit finish, we run the provisioning in a separate thread and report progress.
Created attachment 94733 [details] Patch against p2 incubator project This patch contains my most recent code. To get it to apply, you will need org.eclipse.equinox.p2.target from the Equinox incubator and org.eclipse.equinox.p2.ui.sdk. It currently uses internal p2 code. I'm looking forward to having a new pde plugin to put this code in.
The new plugin org.eclipse.pde.ui.p2 has been created. I will have a patch against it in the near future, but I am currently waiting on some API changes from p2 ui.
Created attachment 95262 [details] Patch to add target provisioner to new plugin Patch against the new org.eclipse.pde.p2.ui plugin. Needs an icon (I was borrowing one from p2). This is pretty much ready to go.
I am encountering a bug in the available IU group with my latest work. Sometimes when expanding categories, the "pending..." placeholder shows up, but the fetch job never runs so it just says pending... forever.
>Sometimes when expanding categories, the "pending..." placeholder shows up, but >the fetch job never runs so it just says pending... forever. Do you know that it never runs? Or runs and then gets cancelled? Or just runs forever? If you run with the ProgressView showing, you'll see those fetch jobs in the view and you can see if they appear, get cancelled, etc. I had some similar problems in this area with item filtering on, when it switched the content provider to a synchronous mode, but I thought I had fixed this. I'm not seeing it in the regular UI. I'll take a look at the patch.
Curtis, I can reproduce this and see the nature of the problem. I'm getting done in by DeferredTreeContentManager (again...sigh...). Its implementation of addUpdateCompleteListener is actually replacing the listeners, so my tracking of which fetches are complete is not right. I'm still debugging to figure out exactly the conditions when this happens (why the main UI doesn't have this problem.) Suffice to say that I'll provide a fix. I am done looking at it for today...In the meantime, a workaround is to type in the filter text, that will fully realize the tree.
Thanks Susan. Chris, when you have time, please review and commit the patch. We can talk about what icon to use. Also, because p2 can handle old update sites, we can consider getting rid of the current update site provisioner.
The p2 UI side is fixed. I didn't have the right default pattern filter set up for you. The update UI code was creating one explicitly, that is why there was a difference. (The default PatternFilter does unnecessary expansions of the tree even when there is no filtering to be done and that conflicts with the timing of the deferred fetch.) Fixed in HEAD. Also, since you are using the "view by site" mode, you probably want to use the bold fonts for filter matches. Add this line of code after you create the available IU group: fAvailableIUGroup.setUseBoldFontForFilteredItems(true); >We can talk >about what icon to use. Also, because p2 can handle old update sites, we can >consider getting rid of the current update site provisioner. My 2 cents: I found it a bit weird to see both provisioners in the wizard. You probably only want the update site provisioner active when the capability for "Classic Update" is active. As for the icon to use: I think you should use the same (site) icon for the provisioner rather than the IU icon, since you are showing the view by site and the wizard is called "Repository or Update Site". Also, a terminology comment. The description for the wizard says: "This provisioner adds new plug-ins from repositories and update sites into your target platform." But the wizard page uses the "Installable Unit" terminology everywhere. We don't use "Installable Unit" anywhere in the update UI, so I suggest you use "plug-ins" in the context of the PDE target provisioner (or feature if that is a more appropriate word). In the main UI we are trying to be agnostic by calling it "Available Software".
(In reply to comment #38) > The p2 UI side is fixed. I didn't have the right default pattern filter set up > for you. The update UI code was creating one explicitly, that is why there was > a difference. (The default PatternFilter does unnecessary expansions of the > tree even when there is no filtering to be done and that conflicts with the > timing of the deferred fetch.) Works great, thank you. > > My 2 cents: > I found it a bit weird to see both provisioners in the wizard. You probably > only want the update site provisioner active when the capability for "Classic > Update" is active. See bug 226334. > Also, a terminology comment. The description for the wizard says: > "This provisioner adds new plug-ins from repositories and update sites into > your target platform." But the wizard page uses the "Installable Unit" > terminology everywhere. We don't use "Installable Unit" anywhere in the update > UI, so I suggest you use "plug-ins" in the context of the PDE target > provisioner (or feature if that is a more appropriate word). In the main UI we > are trying to be agnostic by calling it "Available Software". > Yes, I wasn't sure what terminology to use and never went back to make it better fit in with the main UI. I'll improve the wording shortly. I prefer the IU icon over the update site one because when they open up the target provisioner they'll see a list of IU icons in the table, but this is not a major concern.
Created attachment 95410 [details] Updated patch Updated the terminology. Fixed up the translation files while I was there.
Created attachment 95411 [details] Icon This is the icon I would prefer to use. It would need to be put in the project at icons/obj/iu_obj.gif to work with the most recent patch.
Thanks Curtis. I will commit the initial code soon and I am targetting the 4/15 i-build for this.
committed code to org.eclipse.pde.p2.ui, made some version number changes and aesthetic changes. need to open a bug against the wonderful releng team to get this added to the map file / feature Thanks Curtis.
Thanks for getting this committed Chris. Opened Bug 226711 with releng.
Provisioner is available in HEAD, marking as FIXED. Please file separate bugs against PDE UI for any problems.
