Issue 372: Build on top of an OSGi runtime
Status:  WontFix
Owner:
Closed:  Jun 2010
Project Member Reported by sop@google.com, Dec 29, 2009
 Issue 368  asks for notification plugins, and change I03b0baa6 [1]
has been pending for the better part of a year to add hooks for
some minimal customization.
       
OSGi has become widely adopted in Java communities as a way to build
extensible applications.  Its a fairly complex standard, but the
basic runtime libraries are simple and straightfoward to work with
when building plugins to link into an existing running application.

Load Apache Felix [2] at runtime and configure just enough of
the OSGi environment that we can load user created bundles out
of $site_path.

Create a public interface API bundle that user bundles can link
to through Import-Package statements, but don't offer any of the
implementation through this bundle.  This should help us to make
a stable plugin API where the underlying implementation can be  
reworked without breaking user bundles.

Include a bundle of Guice and Peaberry [3] so users can take
advantage of its type-checked DSL for service registration. 

Initially focus on answering  issue 368  and change I03b0baa6's needs,
but longer-term we should be able to implement any sort of pluggable
workflow ( issue 288 ,  issue 308 ,  issue 273 ,  issue 112 ,  issue 70 ,
 issue 60 ,  issue 65 ) through plugin bundles.

Most of these bundles should be part of our standard download
package.  By forcing us to answer these feature requests through
our own public API, we allow end-users to also build plugins which
we could later just add to our packaging.

[1] https://review.source.android.com/9414
[2] http://felix.apache.org/
[3] https://code.google.com/p/peaberry/


Jan 6, 2010
#1 alex.ble...@gmail.com
Can I suggest the use of declarative services for wiring up the components? That way, you don't even need to 
have any OSGi dependencies in your code.
Jan 6, 2010
#2 sop@google.com
That's a good point.  But we'll still need to link to at least some bits
of OSGi.  Since Gerrit is self-contained at some point we need to load up
the runtime and get our bundles installed.

Primarily I think we want the OSGi runtime for the classloader policy,
it makes it easier to create isolated components that can be dropped in.
Using their services API to connect things up manually in the activator
is a bit old-school; dynamic injection like Eclipse's extension points
or similar is the way to go.
Jun 15, 2010
#3 sop@google.com
Turns out this is just too hard.  Tabling it / never going to
implement it.  :-)
Status: WontFix