Re: Bundling interfaces and implementations

["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

[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

["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

[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