Hi Andrew, On Fri, Mar 5, 2010 at 10:29 AM, Andrew Woods <[email protected]> wrote: > Digging deeper into the "Module+Architecture+Development" wiki page, I would > like to expand on a point mentioned in the "OSGi-friendliness" section. > You mention the favorable practice of separating the interfaces and > implementations into different packages. Using the mentioned > "maven-bundle-plugin" > http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html > automatically generates project jar (or war) artifacts that have the > necessary META-INF/MANIFEST.MF enabling the artifact to be installed into an > OSGi container as a proper bundle. > The MANIFEST created by this plugin exports all packages of the project to > the OSGi container with the exception of: > . (default package) > impl (any package containing 'impl') > internal (any package containing 'internal') > > So naming implementation packages with either 'impl' or 'internal' will have > the desired effect of not exposing implementation classes to other > services/bundles in the container.
Yes, that's good to point out. I've updated the page. Not sure which convention is more commonly used out there. Perhaps "internal" is the more semantically correct term, as you might actually want to export a package that has implementation classes within...as long as they form part of your intended public view of the bundle. > Also, is there a particular reason behind your recommendation to use > constructor injection over property injection in addition to not requiring > getters/setters and knowing that a class has been fully initialized? I'm partial to constructor injection over setter injection mostly because it doesn't clutter the public contract of your classes. Adding getters/setters just to support DI makes it harder for a person to grok how they're supposed to interact with it (is that method really meant for me to use, or is it there to support the DI framework?) Annotations can help to make that clear, but I think it's far simpler to just avoid all the extra methods and use constructors as the entry point for initialization wherever possible. - Chris ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
