You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Steven E. Harris" <se...@panix.com> on 2006/12/06 00:00:57 UTC
Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Richard S. Hall <he...@ungoverned.org> 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.
Advice and examples would be welcome.
--
Steven E. Harris
Re: Bundling interfaces and implementations
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 December 2006 01:51, Steven E. Harris wrote:
> Peter Kriens <Pe...@aQute.biz> writes:
> > 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;
>
> By "its interfaces", do you mean interfaces that it implements, or
> interfaces that it /uses/ expecting someone else to have implemented?
As Richard points out, I am pretty sure Peter is talking about the *public*
interfaces of the bundle. One of the beauties of OSGi is that it allows you
to easily define the *actual* API and protect everything else from abuse.
> For instance, should that every bundle that uses (as a client) the
> OSGi LogService include all of org.osgi.service.log? Or do you just
> mean that the Felix Log implementation includes all of
> org.osgi.service.log?
The latter. But *I* happen to like to go one step further and put the API in a
separate bundle from the implementation. This allows me to upgrade the
implementation without the clients being stopped. And the lower in the stack
you go the sweeter this distinction becomes.
Cheers
Niclas
P.S. It is nice to see so many new faces, and hopefully this is the beginning
of *take off* for OSGi and Felix.
Re: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 December 2006 12:41, Aaron Siri wrote:
> "What Peter's tools has done so far, is to traverse the bytecodes and
> locate all the packages that are referenced one way or the other. A task
> not fit for humans."
>
> But with maven you've already done this with the dependency definitions.
> It wouldn't have compiled otherwise. Maven will also take care of
> dependency dependencies and let you specify packaging intent. The plugin
> then needlessly does a lot of bytecode inspection just to figure out what
> maven already told you was needed. As a stand-alone tool that is slick, as
> a maven plugin it is redundant and confusing.
Well, that is incorrect.
Firstly, every compile I have seen on the market includes rt.jar, which
contains all kinds of classes that must be imported if referenced one, two or
more levels down.
Secondly, everything on the market isn't compiled with Maven. Many projects
out there has been "mavenized" independently and most of them has poms
without dependency information, hence the information is lost.
> Why oh why would you even bring up the jar vs. package debate? For better
> or worse .jar is the standard "packaging" mechanism and packages have been
> regulated to namespace duty. ;) As long as code is delivered via .jars
> why don't we keep it in that format? I don't want to second guess why
> things are packaged as they are. We are just trying to keep our bundles
> neat and organized. :P
Well, the "world is wrong" ;o) and the OSGi community has chosen to state
that, stick by it and evangelize that "package" keyword is more than a
classname prefix (namespace is inapproriate term as well, since the JVM has a
concept of class namespace different from this).
Now, personally I am not much in favour of "inlining", but there are
exceptions. Example; Let's say I use one class in the Jakarta Commons
Collection jar. I don't like to have my bundle depend on a "not yet
bundlized" commons-collection, and sticking a 558kB into my bundle seems a
bit of overkill, especially if it is a very commonly recurring class.
I agree that inling should not be default, but it should be supported.
I disagree that Maven's model is rich enough to support OSGi modelling, and I
doubt that we will ever see a change, partly due to the "WTF do you mean is
wrong with the Jar as the versioned artifact to drive the compile and runtime
cycles?" attitude that is the first reaction when trying to explain the
problem domain to non-OSGiers.
Cheers
Niclas
Re: Bundling interfaces and implementations
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> Why oh why would you even bring up the jar vs. package debate? For better or
> worse .jar is the standard "packaging" mechanism and packages have been
> regulated to namespace duty. ;) As long as code is delivered via .jars why
> don't we keep it in that format? I don't want to second guess why things are
> packaged as they are. We are just trying to keep our bundles neat and
> organized. :P
>
Well, the OSGi framework works in terms of packages, not JARs.
-> richard
> -Aaron
>
>
>
> -----Original Message-----
> From: Niclas Hedhman on behalf of Niclas Hedhman
> Sent: Wed 12/6/2006 8:53 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundling interfaces and implementations (was: Bundle plugin:
> Importing packages from non-bundles)
>
> On Thursday 07 December 2006 00:54, Aaron Siri wrote:
>
>> 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 have not yet taken a proper look at bnd, but your suggestions doesn't sound
>
> sound... ;o)
>
> What Peter's tools has done so far, is to traverse the bytecodes and locate
> all the packages that are referenced one way or the other. A task not fit for
>
> humans.
> Now, it makes a lot sense to me that the tool is *not* authorative in the
> normal case, but defaults to something useful for the average idiot like
> myself. I assume you are refering to such defaults... That can probably be
> achieved, once the principles are agreed upon.
>
> Private-Package sounds like a short-cut to "full review" of the found
> packages
> and essentially Export-Package vs Private-Package is analogous with "allow"
> vs "deny" in Httpd server.
>
> Further, packaging can be done in three ways;
>
> 1. embedding - Put the dependent jar file of classes into the Bundle jar.
> 2. inlining - Put the dependent classes into the Bundle jar
> 3. external - Reference to the requirement in Import-Package/Require-Bundle
>
> The use-cases for 1 vs 2 are probably quite "weak", but old farts like Peter,
>
> myself, Richard (sorry guys) grew up in days where resources were not
> abundant, bark was used as flour and Jack the Ripper was the real reality
> show for whores in London, so we get sick in the stomach when we see a 2MB
> jar file included in a bundle just because a single 2kB class is referenced.
>
> The point Peter always tries to make is that the Jar is a Java after-thought,
>
> a hack and that Sun actually had it more right from day 1, in that the
> package is the natural "container" of classes, and it was only lacking proper
>
> versioning and other annotations from the start. We should be able to ignore
> the Jar itself, take it for what it is; A ZIP file for easy transport.
> Maven, other build systems, the JVMs classpath and endless other systems
> assumes that the jar file carries additional significance, such as being a
> unique identifier of its content, or that the content will only reside in jar
>
> files that follows this particular naming conventions and if the classes
> resurface elsewhere, then "elsewhere" is raping someone elses work.
>
> Ok, a lot of rambling...<stop/>
>
>
> Cheers
> Niclas
>
>
RE: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Aaron Siri <Aa...@efi.com>.
"What Peter's tools has done so far, is to traverse the bytecodes and locate
all the packages that are referenced one way or the other. A task not fit for
humans."
But with maven you've already done this with the dependency definitions. It
wouldn't have compiled otherwise. Maven will also take care of dependency
dependencies and let you specify packaging intent. The plugin then
needlessly does a lot of bytecode inspection just to figure out what maven
already told you was needed. As a stand-alone tool that is slick, as a maven
plugin it is redundant and confusing.
What we are saying is let the pom drive the packaging and the classpath. Let
the plugin do the neat Import/Export stuff it is doing now. We aren't trying
to change how bnd behaves, just how the new plugin behaves. If they are so
tightly coupled that you can't change one without changing the other then
perhaps that is the issue that needs to be addressed.
Why oh why would you even bring up the jar vs. package debate? For better or
worse .jar is the standard "packaging" mechanism and packages have been
regulated to namespace duty. ;) As long as code is delivered via .jars why
don't we keep it in that format? I don't want to second guess why things are
packaged as they are. We are just trying to keep our bundles neat and
organized. :P
-Aaron
-----Original Message-----
From: Niclas Hedhman on behalf of Niclas Hedhman
Sent: Wed 12/6/2006 8:53 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundling interfaces and implementations (was: Bundle plugin:
Importing packages from non-bundles)
On Thursday 07 December 2006 00:54, Aaron Siri wrote:
> 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 have not yet taken a proper look at bnd, but your suggestions doesn't sound
sound... ;o)
What Peter's tools has done so far, is to traverse the bytecodes and locate
all the packages that are referenced one way or the other. A task not fit for
humans.
Now, it makes a lot sense to me that the tool is *not* authorative in the
normal case, but defaults to something useful for the average idiot like
myself. I assume you are refering to such defaults... That can probably be
achieved, once the principles are agreed upon.
Private-Package sounds like a short-cut to "full review" of the found
packages
and essentially Export-Package vs Private-Package is analogous with "allow"
vs "deny" in Httpd server.
Further, packaging can be done in three ways;
1. embedding - Put the dependent jar file of classes into the Bundle jar.
2. inlining - Put the dependent classes into the Bundle jar
3. external - Reference to the requirement in Import-Package/Require-Bundle
The use-cases for 1 vs 2 are probably quite "weak", but old farts like Peter,
myself, Richard (sorry guys) grew up in days where resources were not
abundant, bark was used as flour and Jack the Ripper was the real reality
show for whores in London, so we get sick in the stomach when we see a 2MB
jar file included in a bundle just because a single 2kB class is referenced.
The point Peter always tries to make is that the Jar is a Java after-thought,
a hack and that Sun actually had it more right from day 1, in that the
package is the natural "container" of classes, and it was only lacking proper
versioning and other annotations from the start. We should be able to ignore
the Jar itself, take it for what it is; A ZIP file for easy transport.
Maven, other build systems, the JVMs classpath and endless other systems
assumes that the jar file carries additional significance, such as being a
unique identifier of its content, or that the content will only reside in jar
files that follows this particular naming conventions and if the classes
resurface elsewhere, then "elsewhere" is raping someone elses work.
Ok, a lot of rambling...<stop/>
Cheers
Niclas
Re: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 07 December 2006 00:54, Aaron Siri wrote:
> 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 have not yet taken a proper look at bnd, but your suggestions doesn't sound
sound... ;o)
What Peter's tools has done so far, is to traverse the bytecodes and locate
all the packages that are referenced one way or the other. A task not fit for
humans.
Now, it makes a lot sense to me that the tool is *not* authorative in the
normal case, but defaults to something useful for the average idiot like
myself. I assume you are refering to such defaults... That can probably be
achieved, once the principles are agreed upon.
Private-Package sounds like a short-cut to "full review" of the found packages
and essentially Export-Package vs Private-Package is analogous with "allow"
vs "deny" in Httpd server.
Further, packaging can be done in three ways;
1. embedding - Put the dependent jar file of classes into the Bundle jar.
2. inlining - Put the dependent classes into the Bundle jar
3. external - Reference to the requirement in Import-Package/Require-Bundle
The use-cases for 1 vs 2 are probably quite "weak", but old farts like Peter,
myself, Richard (sorry guys) grew up in days where resources were not
abundant, bark was used as flour and Jack the Ripper was the real reality
show for whores in London, so we get sick in the stomach when we see a 2MB
jar file included in a bundle just because a single 2kB class is referenced.
The point Peter always tries to make is that the Jar is a Java after-thought,
a hack and that Sun actually had it more right from day 1, in that the
package is the natural "container" of classes, and it was only lacking proper
versioning and other annotations from the start. We should be able to ignore
the Jar itself, take it for what it is; A ZIP file for easy transport.
Maven, other build systems, the JVMs classpath and endless other systems
assumes that the jar file carries additional significance, such as being a
unique identifier of its content, or that the content will only reside in jar
files that follows this particular naming conventions and if the classes
resurface elsewhere, then "elsewhere" is raping someone elses work.
Ok, a lot of rambling...<stop/>
Cheers
Niclas
Re: Bundling interfaces and implementations
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Steven E. Harris wrote:
> Peter Kriens <Pe...@aQute.biz> writes:
>
>
>> 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;
>>
>
> By "its interfaces", do you mean interfaces that it implements, or
> interfaces that it /uses/ expecting someone else to have implemented?
>
> For instance, should that every bundle that uses (as a client) the
> OSGi LogService include all of org.osgi.service.log? Or do you just
> mean that the Felix Log implementation includes all of
> org.osgi.service.log?
>
I believe Peter was referring to interfaces you implement, not the ones
that you require.
-> richard
Re: Bundling interfaces and implementations
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Aaron Siri wrote:
> 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?
>
I believe that a middle ground can be reached here...
-> richard
> -Aaron
>
> -----Original Message-----
> From: Peter Kriens [mailto:Peter.Kriens@aQute.biz]
> 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 <he...@ungoverned.org> 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
>
>
>
Re[2]: Bundling interfaces and implementations
Posted by Peter Kriens <Pe...@aQute.biz>.
SEH> Peter Kriens <Pe...@aQute.biz> writes:
>> 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;
SEH> By "its interfaces", do you mean interfaces that it implements, or
SEH> interfaces that it /uses/ expecting someone else to have implemented?
The one that provides the functionality should carry the interfaces.
Depending on the service specification this can both be the
implementer as the user of the Java interface. For example, log
implementer should contain the org.osgi.service.log that contains both
interfaces it implementes (LogService, LogReaderService, LogEntry) and uses
(LogListener).
SEH> For instance, should that every bundle that uses (as a client) the
SEH> OSGi LogService include all of org.osgi.service.log? Or do you just
SEH> mean that the Felix Log implementation includes all of
SEH> org.osgi.service.log?
Yes.
Then again, this is a choice. It makes the bundle standalone and
capable of providing its functionality in every environment without
requiring other bundles, exactly the way I like it.
However, these choices you make when you design the packaging and you
can set it up in many different ways. This is just my personal opinion
of best practice, feel free to do it differently.
Kind regards,
Peter Kriens
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Bundling interfaces and implementations
Posted by "Steven E. Harris" <se...@panix.com>.
Peter Kriens <Pe...@aQute.biz> writes:
> 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;
By "its interfaces", do you mean interfaces that it implements, or
interfaces that it /uses/ expecting someone else to have implemented?
For instance, should that every bundle that uses (as a client) the
OSGi LogService include all of org.osgi.service.log? Or do you just
mean that the Felix Log implementation includes all of
org.osgi.service.log?
--
Steven E. Harris
RE: Re[2]: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Aaron Siri <Aa...@efi.com>.
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:Peter.Kriens@aQute.biz]
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 <he...@ungoverned.org> 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
Re[2]: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by Peter Kriens <Pe...@aQute.biz>.
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 <he...@ungoverned.org> 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 choose,
RSH> since they will all work equally well on the OSGi framework. The main
RSH> issues are that if you separate out interfaces, then you end up with a
RSH> bunch of small bundles needing to be deployed and you essentially have
RSH> 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 framework
RSH> will correctly handle sharing among the different providers properly so
RSH> that they can interoperate (if possible). The main downside to this
RSH> approach is that if you refresh the implementation it will also refresh
RSH> 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
Re: Bundling interfaces and implementations
Posted by Jeff McAffer <Je...@ca.ibm.com>.
"Richard S. Hall" <he...@ungoverned.org> wrote on 12/05/2006 07:00:14 PM:
> On Dec 5, 2006, at 6:47 PM, Aaron Siri wrote:
>
> > If you haven't already taken a look at equinox you should. Eclipse is
> > a good
> > example of an app built atop OSGi from which to learn. If equinox is
> > a bad
> > word around here then I apologize.
> >
> > Anyways, it already has the concept of plugins, extension points, etc
> > built
> > atop OSGi using xml descriptors. You can use it all without any of
the
> > eclipse UI/app framework. Just download the equinox SDK and you'll
> > have
> > almost everything you'll need. We are using it for a web-based
> > application
> > where we and third parties can plug in functionality.
> >
> > BTW, is the equinox/felix relationship friendly?
>
> Sure it is...well, except for that McAffer guy... (sorry Jeff, I
> couldn't resist)
Don't blame you. I likely could not have resisted the inverse jab... ;-)
Truth be known for everyone out there I have the utmost respect for
Richard and all the work being done in Felix. Its great.
> We have a few differences in opinion on "best practices", but otherwise
> we work together and discuss with each other quite regularly.
Too much is likely made of these differences (actually, I likely make to
much of them sometimes). Fact is that all the OSGi communities out there
are keen on modularity, simplicity, dynamic behaviour and see OSGi as a
great vehicle. There are some different usecases and priorities driving
the work being done. Certainly in the Equinox community we are actively
seeking to reduce/eliminate any "containerisms" that we may have.
In short, people should feel comfortable adopting OSGi as a base
technology for their software knowing that this is a cohesive community
and that ultimately they have choices in the implementation they use.
Jeff (aka, "that McAffer guy")
Re: Bundling interfaces and implementations
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Dec 5, 2006, at 6:47 PM, Aaron Siri wrote:
> If you haven't already taken a look at equinox you should. Eclipse is
> a good
> example of an app built atop OSGi from which to learn. If equinox is
> a bad
> word around here then I apologize.
>
> Anyways, it already has the concept of plugins, extension points, etc
> built
> atop OSGi using xml descriptors. You can use it all without any of the
> eclipse UI/app framework. Just download the equinox SDK and you'll
> have
> almost everything you'll need. We are using it for a web-based
> application
> where we and third parties can plug in functionality.
>
> BTW, is the equinox/felix relationship friendly?
Sure it is...well, except for that McAffer guy... (sorry Jeff, I
couldn't resist)
We have a few differences in opinion on "best practices", but otherwise
we work together and discuss with each other quite regularly.
-> richard
>
> -Aaron
>
> -----Original Message-----
> From: Steven E. Harris [mailto:seh@panix.com]
> Sent: Tuesday, December 05, 2006 6:34 PM
> To: felix-dev@incubator.apache.org
> Subject: Re: Bundling interfaces and implementations
>
> Richard S. Hall <he...@ungoverned.org> writes:
>
>> The main issues are that if you separate out interfaces, then you end
>> up with a bunch of small bundles needing to be deployed and you
>> essentially have no self-contained bundles.
>
> Right, that's what I'm seeing emerge. For example, I have one bundle
> right
> now that has one class in it.
>
> The motivating scenario for my application is this: The application
> has a
> couple of "plugin types" (defined as interfaces) for which it expects
> to
> download and install lots of plugins, each of which will be an OSGi
> bundle.
> Perhaps this is analogous to a servlet container; there's one servlet
> API
> set, and lots of servlets that will come along and implement it.
>
> Obviously the application itself needs access to these interfaces, as
> do the
> plugins. The interfaces have no obvious home. If the plugins could be
> developed by third parties, we'd have to make the interface class files
> available in some way, regardless of what bundle they eventually wind
> up in.
> Normally we have these decisions to make about how to organize source
> in a
> tree, how to package it for distribution or deployment, and now with
> bundles
> we have yet another dimension to consider.
>
>> If you expect to have multiple providers of the same service, then
>> maybe it makes sense to package the service interfaces separately.
>
> That sounds more like my situation.
>
>> Unfortunately, there is no single rule.
>
> Even so, we need more example applications built atop OSGi from which
> to
> learn.
>
> --
> Steven E. Harris
RE: Bundling interfaces and implementations
Posted by Aaron Siri <Aa...@efi.com>.
If you haven't already taken a look at equinox you should. Eclipse is a good
example of an app built atop OSGi from which to learn. If equinox is a bad
word around here then I apologize.
Anyways, it already has the concept of plugins, extension points, etc built
atop OSGi using xml descriptors. You can use it all without any of the
eclipse UI/app framework. Just download the equinox SDK and you'll have
almost everything you'll need. We are using it for a web-based application
where we and third parties can plug in functionality.
BTW, is the equinox/felix relationship friendly?
-Aaron
-----Original Message-----
From: Steven E. Harris [mailto:seh@panix.com]
Sent: Tuesday, December 05, 2006 6:34 PM
To: felix-dev@incubator.apache.org
Subject: Re: Bundling interfaces and implementations
Richard S. Hall <he...@ungoverned.org> writes:
> The main issues are that if you separate out interfaces, then you end
> up with a bunch of small bundles needing to be deployed and you
> essentially have no self-contained bundles.
Right, that's what I'm seeing emerge. For example, I have one bundle right
now that has one class in it.
The motivating scenario for my application is this: The application has a
couple of "plugin types" (defined as interfaces) for which it expects to
download and install lots of plugins, each of which will be an OSGi bundle.
Perhaps this is analogous to a servlet container; there's one servlet API
set, and lots of servlets that will come along and implement it.
Obviously the application itself needs access to these interfaces, as do the
plugins. The interfaces have no obvious home. If the plugins could be
developed by third parties, we'd have to make the interface class files
available in some way, regardless of what bundle they eventually wind up in.
Normally we have these decisions to make about how to organize source in a
tree, how to package it for distribution or deployment, and now with bundles
we have yet another dimension to consider.
> If you expect to have multiple providers of the same service, then
> maybe it makes sense to package the service interfaces separately.
That sounds more like my situation.
> Unfortunately, there is no single rule.
Even so, we need more example applications built atop OSGi from which to
learn.
--
Steven E. Harris
Re: Bundling interfaces and implementations
Posted by "Steven E. Harris" <se...@panix.com>.
Richard S. Hall <he...@ungoverned.org> writes:
> The main issues are that if you separate out interfaces, then you
> end up with a bunch of small bundles needing to be deployed and you
> essentially have no self-contained bundles.
Right, that's what I'm seeing emerge. For example, I have one bundle
right now that has one class in it.
The motivating scenario for my application is this: The application
has a couple of "plugin types" (defined as interfaces) for which it
expects to download and install lots of plugins, each of which will be
an OSGi bundle. Perhaps this is analogous to a servlet container;
there's one servlet API set, and lots of servlets that will come along
and implement it.
Obviously the application itself needs access to these interfaces, as
do the plugins. The interfaces have no obvious home. If the plugins
could be developed by third parties, we'd have to make the interface
class files available in some way, regardless of what bundle they
eventually wind up in. Normally we have these decisions to make about
how to organize source in a tree, how to package it for distribution
or deployment, and now with bundles we have yet another dimension to
consider.
> If you expect to have multiple providers of the same service, then
> maybe it makes sense to package the service interfaces separately.
That sounds more like my situation.
> Unfortunately, there is no single rule.
Even so, we need more example applications built atop OSGi from which
to learn.
--
Steven E. Harris
Re: Bundling interfaces and implementations (was: Bundle plugin: Importing packages from non-bundles)
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On Dec 5, 2006, at 6:00 PM, Steven E. Harris wrote:
> Richard S. Hall <he...@ungoverned.org> 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.
Overall, it doesn't really make a difference which approach you choose,
since they will all work equally well on the OSGi framework. The main
issues are that if you separate out interfaces, then you end up with a
bunch of small bundles needing to be deployed and you essentially have
no self-contained bundles.
If you package service interfaces with all of your service
implementations (and both import and export them), then the framework
will correctly handle sharing among the different providers properly so
that they can interoperate (if possible). The main downside to this
approach is that if you refresh the implementation it will also refresh
any dependent clients or other providers.
If you expect to only have one service provider at a time, then it
might make sense to package the service interfaces with the service
impl. If you expect to have multiple providers of the same service,
then maybe it makes sense to package the service interfaces separately.
Unfortunately, there is no single rule.
-> richard