Skip to main content

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

As for 2), the Javadoc for FilterImpl does mention handling for array
values. It appears it handles at as a 'IN' operation. osgi.os=linux
would match when osgi.os has a string array of { "linux", "win32" }.
Proof would be in trying it out I guess.

________________________________

From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Susan Franklin
McCourt
Sent: Thursday, April 03, 2008 12:13 PM
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





 "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


GIF image

GIF image


Back to the top