I actually don't mind import-package vs. require-bundle and reading the spec I have to agree with you that import-package is the recommendation.
My issue is more of a packaging issue and how the plugin interprets the maven environment. The bundle plugin, unless I'm mistaken, rips classes out of dependency, non-bundle jars and puts the classes into the local bundle rather than just embedding the .jar as a .jar and putting it on the classpath. It ignores the maven dependencies for packaging purposes and forces the user to manually figure out which packages are needed and specify them via <Private-Package>. What if we did away with <Private-Package> (or detect a special value) and just assume that all maven jar dependencies are required by the bundle packages with packaging of the jars honoring the dependency definitions (i.e. compile, provided, etc.)? The classpath is added to the manifest. You can Export-Package/Import-Package as done today. Could this work? I'm starting to think that the older osgi-plugin was a better fit with the maven model and that bnd isn't very mavenisable or doesn't translate to maven well. But maybe a happy median can be achieved? -Aaron -----Original Message----- From: Peter Kriens [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 06, 2006 11:06 AM To: Richard S. Hall Cc: felix-dev@incubator.apache.org Subject: Re[2]: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles) I completely concur with Richard. Import-Package is for me the way to go and is even officially preferred by the OSGi Alliance (look at the disadvantages of using Require-Bundle in the spec, and also in my blogs). One reason I like Felix is this fanatic focus on decoupling. The bnd plugin is targeted at making bundles directly from the classpath that use Import-Package to minimize coupling between bundles. Packaging the spec interfaces with the implementation is not only very easy with bnd, I also think that is the right way to go. Last week I worked on a demo and Felix jetty was the only bundle that ran directly out of the box from OBR because it contained all its interfaces; really nice in my opinion. However, this model is very different from the maven policy of transitive dependencies on artifacts. Starting to support Require-Bundle in bnd is therefore counter to its original goal. If you really think you need Require-Bundle, maybe this plugin is not the way to go then. I am afraid that if I add all these features to the plugin it becomes complex and bloated and overriding its original goal. Maybe we need multiple plugins ... Kind regards, Peter Kriens RSH> On Dec 5, 2006, at 6:00 PM, Steven E. Harris wrote: >> Richard S. Hall <[EMAIL PROTECTED]> writes: >> >>> The spec used to recommend packaging a bundle with its >>> interfaces...I am not sure if it still does or not, but it is >>> definitely not anti-OSGi. >> >> Today I've been wondering about this too. In many cases, I wish to >> define some service interface for clients to use, then write at least >> one implementation of the service interface. Clients will rely on the >> interfaces, but should have no knowledge of the implementation(s). >> What's the right way to package this in OSGi? >> >> If I put the interfaces in the same bundle as the implementation, the >> two have to be in different packages to maintain the intended privacy >> of the implementation. Alternately, I can place the interfaces in a >> bundle, and have both the clients and the implementation bundle rely >> on that interface-only bundle. This is based on the assumption that a >> given class or interface should only wind up in one bundle. Also, the >> latter separated approach seems more favorable to there being >> multiple implementations of a single interface, as it wouldn't make >> sense to put the interfaces in the first implementation's bundle and >> have all other implementations rely on the first. >> >> Since Felix is written largely as an implementation of a separate set >> of OSGi interfaces, it's more obvious how it splits the two domains. >> For an application or system that's more self-contained, though, it's >> harder to figure out a discipline for separating interfaces and >> implementations. RSH> Overall, it doesn't really make a difference which approach you RSH> choose, since they will all work equally well on the OSGi RSH> framework. The main issues are that if you separate out interfaces, RSH> then you end up with a bunch of small bundles needing to be RSH> deployed and you essentially have no self-contained bundles. RSH> If you package service interfaces with all of your service RSH> implementations (and both import and export them), then the RSH> framework will correctly handle sharing among the different RSH> providers properly so that they can interoperate (if possible). The RSH> main downside to this approach is that if you refresh the RSH> implementation it will also refresh any dependent clients or other providers. RSH> If you expect to only have one service provider at a time, then it RSH> might make sense to package the service interfaces with the service RSH> impl. If you expect to have multiple providers of the same service, RSH> then maybe it makes sense to package the service interfaces separately. RSH> Unfortunately, there is no single rule. ->> richard -- Peter Kriens Tel +33467542167 9C, Avenue St. Drézéry AOL,Yahoo: pkriens 34160 Beaulieu, France ICQ 255570717 Skype pkriens Fax +1 8153772599
