> On 21/04/07, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
> > I'm not stuck on the name. alternatives would be greatly
> > that there are others like .ds, .scr, .. that are not immediately
> > That is the nature of acronyms. We can go for full descriptive
> > tend to shy away from partial shortenings if possible. decserv
> > initprov is not so bad I guess. But one has to wonder what
we are saving
> > over full names.
> Are you prevented from using org.eclipse.equinox.osgi.provisioning?
> so, then org.eclipse.equionx.initialprovisioning seems like a good
> choice. I don't think there's any great benefit in making the package
> name shorter, other than a nod to the amount of extra space that would
> be consumed by the permgenspace for the UFT8 constant.
There is nothing preventing the use of "osgi"
in the name. It just seems redundant given the focus of Equinox.
> > Anyway, like I said, I'm open to suggestions.
Remember that in general we
> > have a policy of coordinating the bundle name and the "dominant
> > name. That is, whatever bundle name we choose will likely
be reflected in
> > various ways in the package names.
> 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