Community
Participate
Working Groups
Targets can contain a variety of things (provided by different types of bundle containers). Currently we simply get a list of bundles from each container and combine them to create the target. Directories are lists of files, Installations are bundle lists from bundle info. Site containers install items into a profile. The p2 profile is a powerful tool that we can leverage to manage the set of bundles. When a site container is included, we already have a significant amount of code to manage bundles using the profile. Expanding the usage of the profile to installations and directories should not be too difficult. The largest obstacle will be obtaining or generating the necessary p2 metadata for the bundles.
I'm investigating this immediately.
This is probably a dupe of 274919: [target] manage whole target using p2 profile https://bugs.eclipse.org/bugs/show_bug.cgi?id=274919 In the end, we need to do a couple things: 1) have a local PDE metadata repo 2) run the p2 publisher on other bundle containers to generate proper metadata I think this would cover it. I've already explored some of this Curtis so we should chat. The first step is to creating a local PDE metadata repo (where in the code we would do this) One thing that bothers me about the current design of targets is that we couple locations with what artifacts we want from them. For example, it would be more powerful to specify the IUs I want and a list of locations to search from.
I didn't see that other bug and it wasn't linked on the plan. Since there aren't any additional comments on that bug I'm just going to dupe it to this one. This bug is trying to accomplish a lot of things, so it may end up being easier to break it down into smaller bugs. I will also likely branch PDE for this work. Work items: 1) Make a profile for the target I think using a profile makes more sense than a metadata repo. The profile can act as a repo and allows us to set some additional properties. It also fits in well with how the site containers currently work. 2) Filter the bundle list (included/excluded/duplicates) after the profile is populated This will help alleviate the coupling between locations and the final bundle list that Chris mentioned at the end of his comment. Some people only care about a specific set of bundles and don't care where they come from. Some people only care about locations. The way I see this working in the UI is that the profile would contain all bundles found in the locations (including duplicates). The target definition could then provide lists of bundles filtered by what the UI needs: duplicates could be gray, included bundles would be checked, source bundles get a different icon. 3) Use the profile to enable faster startup Resolving a target definition can be slow, especially with site containers. We want the active target definition to be resolved and available on startup. Each container will have to handle this differently, but we can hopefully use the metadata in the profile along with some extra stored properties to determine if all the required bundles are available locally. 4) Use the profile as a meta repo to provide metadata to pde build
*** Bug 274919 has been marked as a duplicate of this bug. ***
Started a document describing the proposal: http://docs.google.com/Doc?docid=0Aci3ThIoEgAOZGY2bThjbmtfMWczd3ZicWRz&hl=en In this proposal, the containers would provide repos and IUs. The UI would be changed to look at the metadata rather than resolved bundles (so the files wouldn't have to be downloaded/exist yet). When resolving we would create a profile and install the IUs (including the download phase). An alternative would be to use the profile to manage everything in the target definition for the UI. This could be a big win when it comes to simplifying the UI code. However it requires that IUs can be installed into a profile without the artifacts being available and that the profile is flexible enough in storing the information the UI needs (duplicates, source bundles, etc.) I need to think some more about the UI as there are two primary cases: 1) p2 style - use a set of locations (local, remote, etc.), want a certain set of root IUs and their dependents in the target. 2) manual style - add one or more locations (local), take everything in them, or a specific set of bundles (or possible a specific set of features).
"Each container will provide a set of IUs" Is this the right approach? I think this is a mistake currently as we don't have separation of the things we want and where they come from.
(In reply to comment #6) > "Each container will provide a set of IUs" > > Is this the right approach? I think this is a mistake currently as we don't > have separation of the things we want and where they come from. > The IUs provided by the container would be the complete set. The user could then choose the things they want from a complete list. We need a way to collect all possible IUs before the user says what they want. In the case you describe the user would add some locations then on the content tab they would see a list of bundles (or possibly features) that are currently included. No indication would be given for where they come from unless the user changes the group by settings.
Not sure where you are at this point but one thing to keep in mind using profiles is that you should not expect them to resolve. One of the key characteristics of target platforms is that they are collections of bundles that are *available* to use. In any given situation (e.g., .product or .launch) a subset of these will be used. For exampel, in the Toast work (now in Examples project) we have a .target that includes RAP, RCP, EMF, ECF, Equinox, EclipseLink, ... Some of these things are mutually exclusive from a runtime point of view but at development time the bundle dependencies spec the compile path and all is well. We then have .products that slice and dice the target/workspace to make a runnable profile. check out http://wiki.eclipse.org/Toast This workflow/usecase works today and has worked for a while so it would be great if it continued to work as it is very cool. So, if you want to use profiles under the covers to capture the contents of a Target Platform, that sounds great. But you don't have to run the p2 Planner when creating the ProvisioningPlan used when driving the Engine to change the Profile. You can put whatever you like in the Profile. It can be multi-platform, conflicting, ... Remember the discussion we had around the need for populating targets using software sites and using the slicer rather than the planner...
We have done a lot of work in the target_api_changes branch of pde core/ui/tests but we have decided that it is too risky of a change for M5. There was still some missing functionality and there are quirks to the p2 engine that we haven't sorted out yet. We will investigate what parts could be added in M6, but we will probably avoid changing the provisional API in 3.6
For those who are interested in the proposed API, I will update the google doc that is linked to on this bug. http://docs.google.com/Doc?docid=0Aci3ThIoEgAOZGY2bThjbmtfMWczd3ZicWRz&hl=en It appears there google docs is having some technical problems at the moment but I will update the doc when I can.
There is a large amount of work complete towards this bug and its many dependents done in the target_api_changes branch. The new API solves a number of the outstanding bugs against targets and would have made some future features easier. However, the code was not in a stable state as we hit M5. We are not comfortable putting in a big change like this so late in 3.6 without being reasonably sure about its stability. Not having a working target platform can cripple Eclipse. We will bring parts of the branch in during 3.6 to solve specific problems. In early 3.7 we will take another crack at this.
Marking this bug as a readme. The code is available for reference, but we are no longer considering moving targets to be profile based.
