| Issue 372: | Build on top of an OSGi runtime | |
| 4 people starred this issue and may be notified of changes. | Back to list |
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
Jan 6, 2010
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
Turns out this is just too hard. Tabling it / never going to implement it. :-)
Status:
WontFix
|
|
| ► Sign in to add a comment |