[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
> - "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

Must avoid Boolean valued anything.

> really
> wondering why categories and group / fragments are not handled the
> same?
> Also "iu.fragment" is a weird name.

Consistency here would be good and I agree that iu.fragment is strange

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

Agreed that having "osgi" there is strange.  Not sure that just ws, os, ...
is appropriate.  This should be subject to the same qualification terms we
define elsewhere

> 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?

Don't think we want to use an org.osgi namespace here.  We don't qualify
"osgi" with "org." anywhere else in Equinox.  Perhaps we just remove the
"osgi" part?  Dunno, there might be other kinds of bundles being delivered
in the future.

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

Not sure here but it needs to be easy to find source bundles and to find the
source bundle for a particular bundle.

> 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?

The Eclipse touchpoint talks a lot about bundle pooling and other things
that are specific to Eclipse right?  I could see it being Equinox but am not
so sure we are general enough to call it osgi.

> 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?

Not sure what you mean here.  As I recall, the type and classifier were
there to help with auto-indexing of the repo.  Not sure that is still needed
because of the mapping rules.  Personally I would use equinox and bundles.
Not sure if/why the native guy has "bundles" associated with it.

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

Why don't properties need to be qualified?  Not sure putting iu on the front
of things helps.  Is there another kind of description that is relevant

> - remove osgi of the filters

+1 but not sure they should then be unqualified.

> For bundles, features etc.
> - Ask the opinion of BJ and Peter about the name we should use for
> bundles.

Don't see the need for this.  They will say no because it is not something
that OSGi wants to define at this point.  Not sure what it gets us.

> - Use "java.packages" for packages. Is there any trademark issue with
> that?

+1 unlikely TM issues