[jsword-devel] OSGi update

[DM Smith]

Phillip,
	This is super. So, if I understand correctly, prior to Eclipse 3.2  
working with OSGI bundles is very unfriendly. But the Equinox  
implementation in 3.2 is reasonably supported. If we do go this route  
of adding OSGi as standalone then I think it would be good to have  
the gory details.

	I think Logger and Converter are two good examples. In the case of  
Logger, Common provides the behavior and it would be reasonable for  
it to be replace in a particular application.

	WRT Converter, the implementations are entirely outside of Common,  
so it would be an optional extension to provide. Optional because it  
is conceived that Common might be used by something other than JSword  
and that something might not do xml transformations.

	Keep us posted.

Many Thanks!
	DM

On Dec 12, 2006, at 11:19 PM, P. R. B. wrote:

> Hi all,
>
> Okay, here's how far I've gotten so far. First, some quick  
> definitions for this message, to avoid confusion:
>
> Bundle: an OSGi-compatible bundle that has no dependency on  
> anything related to a specific implementation of OSGi (e.g.  
> Equinox / Eclipse, Knopflerfish). By the nature of OSGi bundles,  
> there are no extension points for plugins to connect to.
>
> Plugin: an Eclipse / RCP plugin. Plugins are bundles, but bundles  
> aren't plugins. Plugins may provide extension points for other  
> plugins, may provide extensions to other plugins' extension points,  
> or both.
>
>
> The executive summary:
>
> A new plugin created in Eclipse 3.x can easily be reduced to a  
> bundle. I was able to convert Commons to a simple bundle without  
> coding changes, and I was able to make calls to said bundle's  
> classes from another bundle. The call to Commons required hitting  
> Apache code (which depends on other Apache code, and so on), so  
> bundle dependency chains work as expected. It all ran successfully  
> from within two different OSGi framework implementations.
>
> The longer version:
>
> My goal for getting a feel for OSGi was to turn the Common jar into  
> a simple bundle, and make a call to its code from a separate  
> bundle. The OSGi spec for a bundle's manifest file is difficult to  
> manage manually, so I thought I'd find an Eclipse plugin that could  
> simplify this for me, moreso than Eclipse's built-in plugin editor.  
> My first go was with Knopflerfish (http://www.knopflerfish.org).  
> They provide an Eclipse plugin to create custom bundle projects and  
> a UI-based OSGi framework. I was discouraged by a couple things in  
> the plugin. First, a bundle isn't exported correctly from a bundle  
> project using the standard "Export..." action; it has to be  
> exported through a button in a custom editor tied to a  
> bundle.manifest file. Second, I couldn't find a way to make one  
> bundle completely dependent on another like I can when working with  
> plugins (the functionality may be there, but I couldn't find it).  
> The OSGi framework itself is slick, but the plugin didn't help me  
> much.
>
> Next I looked at Equinox, which is what Eclipse (now) uses for its  
> OSGi framework implementation. Eclipse 3.2 allows a plugin to be  
> created that targets Equinox. In other words, it creates a bundle  
> and not a plugin, and all plugin-related editors also handle bundle  
> properties. Using Eclipse 3.1 to create a bundle required a little  
> more work. I had to modify the new plugin's manifest and code to  
> remove its dependency on the org.eclipse.osgi bundle. The changes  
> were minor, but worth noting.
>
> I was able to create the Common bundle in Eclipse this way, along  
> with a test bundle that would call some Common code when the test  
> bundle was activated. I had already created plugins for the various  
> jars that Common depends on. These plugins were simple enough to  
> qualify as bundles (no extensions, no plugin.xml, etc), so I used  
> them to fulfill the Common bundle's dependencies. I took this batch  
> of bundles and loaded them into the Equinox command line OSGi  
> console, and the test bundle made its call successfully when it  
> started up. I did the same with the bundles in the Knopflerfish  
> console.
>
> Going forward, I'll look at the Common code to determine what  
> classes need to be changed to make them bundle- and plugin- 
> friendly. Logger and Converter are the first two that come to mind.  
> I imagine we'd want a plugin wrapper to be able to use its own log  
> for output and provide Converter extension points to allow other  
> plugins to add converters. I don't know whether these can be done  
> in a practical manner or not yet. I'll also consider the classes  
> that DM listed. I'll post what I come up with.
>
> Let me know if anyone is interested in knowing the specific steps  
> to create the bundles and test them. I can write them up and post a  
> link to them here.
>
> Thanks,
> -Phillip
>
>
> Check out the all-new Yahoo! Mail beta - Fire up a more powerful  
> email and get things done faster.
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/jsword-devel/attachments/20061213/e9384a7a/attachment.html