[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] new services
|
On 24/04/07, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
> Are you prevented from using org.eclipse.equinox.osgi.provisioning? If
> so, then org.eclipse.equionx.initialprovisioning seems like a good
> choice.
There is nothing preventing the use of "osgi" in the name. It just seems
redundant given the focus of Equinox.
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.
> Speaking of which, what's up with the number of things prefixed with
> 'equinox'? Some items, like the provisioning, don't seem to be
> particularly Equinox specific. There's also a point that some of these
> OSGi-related services would happily run (and do) on different OSGi
> engines; the name doesn't particularly help advertise the fact that
> they're not Equinox- (or even Eclipse-) specific.
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.
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.
Anyway, I only raise this as an observation; I'm just an outsider, so
feel free to ignore me :-)
Alex.
