[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [equinox-dev] [prov] p2 filtering

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: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Susan Franklin
McCourt
Sent: 04 April 2008 22:04
To: Equinox development mailing list
Cc: Equinox development mailing list; equinox-dev-bounces@xxxxxxxxxxx
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"
<Helmut.Haigermoser@xxxxxxxxxxxxx>"Haigermoser, Helmut"
<Helmut.Haigermoser@xxxxxxxxxxxxx>




	


				"Haigermoser, Helmut"
<Helmut.Haigermoser@xxxxxxxxxxxxx>
				Sent by: equinox-dev-bounces@xxxxxxxxxxx


				04/04/2008 02:41 AM
				Please respond to Equinox development
mailing list



To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
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: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Susan Franklin
McCourt
Sent: 03 April 2008 18:13
To: Equinox development mailing list
Cc: equinox-dev@xxxxxxxxxxx; equinox-dev-bounces@xxxxxxxxxxx
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"
<Helmut.Haigermoser@xxxxxxxxxxxxx>"Haigermoser, Helmut"
<Helmut.Haigermoser@xxxxxxxxxxxxx>







"Haigermoser, Helmut"
<Helmut.Haigermoser@xxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx


04/03/2008 12:57 AM
Please respond to Equinox development
mailing list



To: <equinox-dev@xxxxxxxxxxx>
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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev