[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] [prov] ID consistency in the metadata

>- Installable units have a type which is used to differentiate between IUs.
>The name of this property is "org.eclipse.equinox.p2.type" and can
>currently take 2 values ("iu.fragment," "group"). Similarly to this type we
>have the "categoryIU" property whose value can be set to "true". I'm really
>wondering why categories and group / fragments are not handled the same?
>Also "iu.fragment" is a weird name

In bug
I think we decided we'd rather group be a property.  We said that capabilities should only be used to express things actually satisfied in the resolver.  So I'd like to see those two things be properties.  I don't know how "iu.fragment" is used, so I can't say what that should be.

As for consolidating these things under something like type.  Originally we discussed that filtering repo content for the user might be different for different products.  So we didn't want to necessarily make "category" a first class notion, but rather different UI's could filter the IU's in a repo however they choose.  The IQueryProvider API makes this possible.  There's nothing hard-coded in the UI that says categories are always shown first.  So if we really think that product X might define a new property on which to filter what the user sees in a repo, then I don't like having a "type" property with predefined values.  Something might be a category and a "foo" or a group and a "foo."


Inactive hide details for Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>

          Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
          Sent by: equinox-dev-bounces@xxxxxxxxxxx

          02/20/2008 06:45 PM
          Please respond to Equinox development mailing list

To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Subject: [equinox-dev] [prov] ID consistency in the metadata

Our metadata is full of identifiers who, even though we don't declare any
API in 1.0, become de-facto APIs since they will be available in

The purpose of this email is two-fold:
1) Verify metadata consistency (review how/why things are express the way
they are and make sure things they all make sense)
2) Reach naming consistency (things are equinox.p2, others are
org.eclipse.equinox.p2, etc...)

After a review of what we have and some embedded questions, I propose some
changes. Please chime in.


Installable Units
- "org.eclipse.equinox.p2.iunamespace" is the namespace in which the
identifier of every IU is made available. It can be used in capabilities
and requirements.
- Installable units have a type which is used to differentiate between IUs.
The name of this property is "org.eclipse.equinox.p2.type" and can
currently take 2 values ("iu.fragment," "group"). Similarly to this type we
have the "categoryIU" property whose value can be set to "true". I'm really
wondering why categories and group / fragments are not handled the same?
Also "iu.fragment" is a weird name.
- IUs also have a lot of properties carrying information such as:
description (equinox.p2.description), name (equinox.p2.name), etc... See
the IInstallableUnit interface.
- The IUs carrying configuration information usually have a capability
whose namespace is "flavor". Why is this not qualified like any other name?
- IUs have an applicability filter. Most of our filters are expressed in
terms of "osgi.ws", "osgi.os", "osgi.arch". The presence of osgi in the
name of these filter does not seem appropriate since they are used to
filter arbitraty things. What don't we simply call those "os", "ws",

Type for the things delivered by the IU
In 1.0 our main focus is on eclipse things: bundles, source bundles,
features, packages. To represent all those we have defined the following
- "osgi.bundles", who describe the symbolic id of the bundle delivered by
the IU. Should that be more qualified like "org.osgi.bundles"? Should we
talk to the OSGi Alliance?
- "osgi.packages", who describe the packages delivered in the IU. I think
this should likely be renamed into "java.packages".
- "osgi.source.bundles", this provides a capability with the name of the
source bundle itself. It is not used in any requirement _expression_. Do we
want to keep it? Would not it be smarter / more useful to have a capability
saying which bundle it is the source of?
Also in order to distinguish between a bundle, a feature and a source
bundle we have the "org.eclipse.equinox.p2.eclipsetouchpoint.types"
namespace which can take "bundle", "feature", "source" as value.

Touchpoint types
We currently have 2 touchpoints: eclipse and native. Should the name of
these be more general? Should the eclipse one be renamed to "osgi" (or
something like that) and have the eclipse specific things in another

The namespace of artifact keys are just used as an indexing mechanism in
the repository. We currently define "eclipse", "native" and for each one of
them we have "plugins". Should we change the "eclipse" one to be more

Other things
Outside of the metadata we have system properties (e.g.
"eclipse.p2.data.area") that are in the eclipse.p2 namespace and also
profile properties (e.g. "eclipse.p2.install.features") ,

For IUs:
- having every namespace id who contains p2 be prefixed with
"org.eclipse.p2.", have flavors also be prefixed
- have IU properties be either just their short name (e.g. description
instead of equinox,p2.description) or be prefixed with iu (e.g.
- remove osgi of the filters

For bundles, features etc.
- Ask the opinion of BJ and Peter about the name we should use for bundles.
- Use "java.packages" for packages. Is there any trademark issue with that?

equinox-dev mailing list

GIF image

GIF image

GIF image