You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2005/08/18 22:28:32 UTC
Package naming conclusion
Ok, I think we have finally reached some sort of conclusion about
package naming. The majority of people [now] appear to feel that we
should have "felix" in the package naming structure and it should be the
root of everything, so that is how it will be.
However, some people have pointed out (blame Jeff McAffer) that it
doesn't make sense to have "service" and "bundle" subpackages, since it
is not necessarily easy to separate out bundle code and that this is
really just a packaging issue any way and not something the programmer
should be worrying about. I agree with Jeff's point and it is definitely
true that just like using "osgi" in the package name is making a grand
assumption, so is using "bundle".
From my understanding, Eclipse does not use a "bundle" subpackage, but
they do use a "service" subpackage. However, (blame Jeff McAffer again)
it is also clear that any interface could be a service interface, so it
really doesn't make sense to have a "service" subpackage either.
To be the most flexible, I propose the following package structure
(where o.a.f == org.apache.felix):
o.a.f.framework // contains the framework impl
o.a.f.<n> // everything else
So, in this case <n> could be a tool subproject, a bundle impl, or a
service interface definition package. How they are bundled or whether
they are bundled at all is a completely independent issue.
However, within the Felix project, we can follow a common approach for
services and their impls, like:
o.a.f.shell // contains service interface defs
o.a.f.shell.impl // contains service impl
o.a.f.shell.impl2 // contains alternate impl
The main benefit of this approach is that impls are logically related to
their service interfaces and it doesn't pollute the o.a.f package as
much. If a service is purely related to the framework, then its impl
would go in the framework package, e.g.:
o.a.f.framework.packageadmin
Or something similar.
The thing to be clear with here is that this is just a guideline for the
Felix project and not a recommendation for how every other project must
structure their bundles. There may even be cases within Felix where
these guidelines cannot be followed, such as if a bundle implements two
different service interfaces.
I hope everyone is happy with this compromise so that we can move on to
fun things...not that this discussion hasn't been fun. ;-)
-> richard
Re: Package naming conclusion
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 August 2005 04:28, Richard S. Hall wrote:
> I hope everyone is happy with this compromise so that we can move on to
> fun things...not that this discussion hasn't been fun. ;-)
Yeah, +1...
Cheers
Niclas
Re: Package naming conclusion
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Jeff McAffer wrote:
>And here I was trying to stay out of this discussion...
>
>
Well, I needed to cite you for the "Eclipse precedent" and to have
someone to blame if this scheme collapses in the future. ;-)
-> richard
Re: Package naming conclusion
Posted by Jeff McAffer <Je...@ca.ibm.com>.
And here I was trying to stay out of this discussion...
The only additional information I have to offer is
- Eclipse uses "service" in the package names mostly out of a convention
that the OSGi folks have been using for some time now
- The conventions you set up will be followed by everyone (witness the
previous point)
- We tend to have the package names relate somehow to the symbolic id of
the encapsulating bundle. This is just to help manage the namespace. Take
a look at any Eclipse bundle for some examples.
Jeff
"Richard S. Hall" <he...@ungoverned.org>
08/18/2005 01:28 PM
Please respond to
oscar-dev
To
oscar-dev@incubator.apache.org
cc
Subject
Package naming conclusion
Ok, I think we have finally reached some sort of conclusion about
package naming. The majority of people [now] appear to feel that we
should have "felix" in the package naming structure and it should be the
root of everything, so that is how it will be.
However, some people have pointed out (blame Jeff McAffer) that it
doesn't make sense to have "service" and "bundle" subpackages, since it
is not necessarily easy to separate out bundle code and that this is
really just a packaging issue any way and not something the programmer
should be worrying about. I agree with Jeff's point and it is definitely
true that just like using "osgi" in the package name is making a grand
assumption, so is using "bundle".
From my understanding, Eclipse does not use a "bundle" subpackage, but
they do use a "service" subpackage. However, (blame Jeff McAffer again)
it is also clear that any interface could be a service interface, so it
really doesn't make sense to have a "service" subpackage either.
To be the most flexible, I propose the following package structure
(where o.a.f == org.apache.felix):
o.a.f.framework // contains the framework impl
o.a.f.<n> // everything else
So, in this case <n> could be a tool subproject, a bundle impl, or a
service interface definition package. How they are bundled or whether
they are bundled at all is a completely independent issue.
However, within the Felix project, we can follow a common approach for
services and their impls, like:
o.a.f.shell // contains service interface defs
o.a.f.shell.impl // contains service impl
o.a.f.shell.impl2 // contains alternate impl
The main benefit of this approach is that impls are logically related to
their service interfaces and it doesn't pollute the o.a.f package as
much. If a service is purely related to the framework, then its impl
would go in the framework package, e.g.:
o.a.f.framework.packageadmin
Or something similar.
The thing to be clear with here is that this is just a guideline for the
Felix project and not a recommendation for how every other project must
structure their bundles. There may even be cases within Felix where
these guidelines cannot be followed, such as if a bundle implements two
different service interfaces.
I hope everyone is happy with this compromise so that we can move on to
fun things...not that this discussion hasn't been fun. ;-)
-> richard