Re: [equinox-dev] new services

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Alex Blewitt wrote on 04/24/2007 05:30:02 PM:

> On 24/04/07, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
> Equinox has two types of bundle, it seems:
> 
> o Implementation of standard OSGi services (e.g. provisioning,
> declarative services, http service)
> o Implementation of other bundles which aren't in any part of an OSGi
> specification that are useful for Eclipse (e.g. provisioning,
> extension registry etc.)
> 
> I was suggesting using a common prefix to distinguish these two, not
> to re-confirm what kind of bundle they were.

yes, this has been debated somewhat in the past. In
the end the team did not feel there was anything particularly compelling
about the fact that one bundle implemented a standard service and one implemented
a service developed/defined by the Equinox team.  Implementing the
standard does not imply that your implementation will run on other frameworks.
 For example, until recently, all Declarative Services implementations
were tied to particular framework implementations.  From the consumer
point of view these services are just useful pieces of function, it doesn't
really matter whether they are standard or not.

As you rightly point out, what does matter is the
consumer's ability to easily understand whether or not a particular service
is available in a wide range of execution scenarios (e.g., on other frameworks).
 That can be either because the other framework team has implementations
of their own (standard or not) or because the Equinox implementation can
run in various places.  To date we have not done very well at expressing
this characteristic.  We have however been working hard to make the
answer a unanimous "yes" (ie., have Equinox bundles run on any
R4 framework implementation).  We are in the process of developing
a mechanism for better exposing our available bundles and capturing their
characteristics and status on the web.  Look for this in the coming
weeks.

> > The bundles come out of the Eclipse Equinox
project. That is where they get
> > their namespace.  This pattern is true of all the OSGi implementation
> > vendors (Felix, KF, Prosyst, ...).  Java package naming
conventions call for
> > the use of the originating organization's domain name as a way
of managing
> > the namespace.  That is all we are doing here.
> 
> I'm not debating the common org.eclipse prefix; but there's a
> difference between 'equinox' (the OSGi implementation), 'equinox'
the
> package prefix, and 'equinox' the project, and they're all conflated.
> For example, the actual core of 'equinox' (the OSGi implementation)
is
> in fact in org.eclipse.osgi.

That is legacy and we cannot change it.  As I
have said in the past, org.eclipse.osgi was choosen at a time when we thought
"equinox" as a project would disappear once the OSGi integration
was complete.  We did debate using org.eclipse.equinox at the time
but felt that that would not be consistent in world where that bundle was
just part of the "runtime".

It is natural that "equinox" the project
name cross over into the package namespace.  Pretty much all Eclipse
projects that I know of do the same thing.  org.eclipse.jdt, org.eclipse.pde,
...

> When others are comparing the OSGi implementations,
it's not clear
> which meaning of 'equinox' is being used in each case, or for that
> matter, which ones would work on other OSGi implementations like KF
> etc.

I agree. See above.  Note as well that other
OSGi communities have exactly the same issue.  In the end we use names
that correlate with the Java package names (or rather we use a similar
mechanism in determining bundle names) so this overlap is bound to occur.

Jeff