Thanks Susan, as usual, your help is highly appreciated! :) My next steps here will be to look at the mentioned interfaces IQueryContext and IPlanValidator once they are available, 'll comment on them once I got the picture :)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Franklin McCourt Sent: 04 April 2008 22:04 To: Equinox development mailing list Cc: Equinox development mailing list; [EMAIL PROTECTED] Subject: RE: [equinox-dev] [prov] p2 filtering Helmut, I'm hoping to get the changes I described re: QueryContext into the next I-build. It's currently tangled up in some work I'm debugging which is not quite stable for release. If I don't get the other changes in, I'll see how easy it would be to get the new API in so you can start with that. I meant to also mention that you should take a look at IPlanValidator. That is how you can plug in your own management of invalid plans, whether to let the user work with them at all, etc... susan Inactive hide details for "Haigermoser, Helmut" <[EMAIL PROTECTED]>"Haigermoser, Helmut" <[EMAIL PROTECTED]> "Haigermoser, Helmut" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/04/2008 02:41 AM Please respond to Equinox development mailing list To: "Equinox development mailing list" <[email protected]> cc: Subject: RE: [equinox-dev] [prov] p2 filtering Ciao Susan :) Thanks a lot for your answers. We certainly want to use that query context, this can aid us in these two aspects: - entitlement - UI selection / custom selection Is this code going to be released to HEAD any time soon? I was about to start work on our custom query provider basically implementing the same concept, looks like you guys are doing this for us now :) Regarding the ProvisionPlan, this sounds like we need to make sure its sanity at various stages in the UI progress or will end up with an uninstallable set of IUs once the user presses "finish", but this can be managed . So thanks a lot again, I appreciate the quick responses!! :) Ciao, hh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Franklin McCourt Sent: 03 April 2008 18:13 To: Equinox development mailing list Cc: [email protected]; [EMAIL PROTECTED] Subject: Re: [equinox-dev] [prov] p2 filtering Hi, Helmut. I'll take a stab at these, although I don't know about #3. 1) First ask the user what hosts/archs etc. he wants to install and then use that information in both the UI and the installation itself. Is this possible at all? The specific notion of considering the profile values for filtering is discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=225365. Also, I'm working now on bug #216028, which provides alternate presentations of the available IU list (flat/by site/by category). To achieve this, I needed additional context, also. What I've done (not released yet) is add the notion of a QueryContext that can be set on any QueriedElement. The QueryContext can be used to determine what the exact query type should be, and in addition, the IQueryProvider can access it while building the query. For example, both the category and flat view are query type of AVAILABLE_IUS, but now the query provider and look into the query context and see if there is more info regarding grouping or filtering. Clients can install the context they want on the model elements. So..conceivably, if we don't yet implement profile-based filtering, this is something you could add by installing a query context into the elements. 2) Can a profile have multiple values for the same property? Like osgi.os=linux&&win32? I don't think so, someone please correct me if I'm wrong about this. 2.1) Profiels.getParent(): I've seen the concept of child/parent profiles, this might help answer question #2, This is really a placeholder concept based on experience with products in the provisioning space. Right now, p2 doesn't use it as a base level, but when the requirements were being discussed, this was an important concept in some installations. 4) I managed to get a lot of IStatus.ERROR in my ProvisionPlan, is checking the plan for errors the right way to look at the sanity of the set of IUs I want to install? Yes, an ERROR status on the plan means that the plan will not work. an OK means it will. With other status severities in between (INFO, WARNING), it's possible to pass the plan to the engine and something will happen (depending on the code/nature of the status.) Right now in the SDK UI, we do not let the user try a plan if it is not OK. In the Admin UI, we have a preference that allows users to try non-OK plans anyway. This would be up to your UI. susan Inactive hide details for "Haigermoser, Helmut" <[EMAIL PROTECTED]>"Haigermoser, Helmut" <[EMAIL PROTECTED]> "Haigermoser, Helmut" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 04/03/2008 12:57 AM Please respond to Equinox development mailing list To: <[email protected]> cc: Subject: [equinox-dev] [prov] p2 filtering Ciao Guys :) It surely is a busy time for you guys, let me thank you for putting some effort into answering my questions regardless of the huge efforts you are putting into M6/M7 right now! :) When looking at the platform's metadata repositories filtering is quite heavily used to flag IUs as being for a specific host/arch/ws (osgi-wise) which is why I thought this concept might be the right choice in our filtering as well. However, some things are yet unclear to me, our strategy of using filters might need to change depending on the answers you are able to give here. Let's start with the one-liner, plz correct me if I'm wrong: Filters are conditions for installing an IU, conditions that need to be fulfilled by the Profile. Right? One example: If the IU has a filter of osgi.os=win32 the IProfile needs the property osgi.os set to "win32" (and only to that) in order for the Framework (Slicer.isApplicable()) to allow an installation. Assuming my statement to be (more or less ;)) true I have some questions along the way: 1.) UI : When presenting IUs to the user a query provider is consulted, but there is no IProfile context to filter the UI (thinking about the AVAILABLE_IU type). Here is what we want to do: First ask the user what hosts/archs etc. he wants to install and then use that information in both the UI and the installation itself. Is this possible at all? Are you guys thinking about this as well? 2.) Profiles: Can a profile have multiple values for the same property? Like osgi.os=linux&&win32? 2.1) Profiels.getParent(): I've seen the concept of child/parent profiles, this might help answer question #2, however, not sure how this might be accomplished... 3.) Dependencies: What's the proper filtering mechanism in terms of dependencies, i.e. what needs to be given the filter: the root-iu, config-ius, ius containing artifacts, all of them? 4.) Dependency errors during installation: Playing around a bit I managed to get a lot of IStatus.ERROR in my ProvisionPlan, is checking the plan for errors the right way to look at the sanity of the set of IUs I want to install? Thanks a lot for helping here, your help is certainly appreciated! :) Ciao, hh _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
