[equinox-dev] [prov] ID consistency in the metadata

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

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
repositories.

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.

PaScaL

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",
"arch"?

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
namespaces:
- "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
touchpoint?

Artifacts:
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
specific?

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") ,


Changes
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.
iu.description)
- 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?