[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] new services


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