[jsword-devel] OSGi plugin opportunity

P. R. B. dysbiote at yahoo.com
Mon Dec 11 12:37:39 MST 2006

I'll start taking a look at that this week, particularly related to the following thoughts: 

OSGi runs a service model. Our concept of plugins wouldn't make for a perfect match with an RCP plugin. The RCP plugin, on activation, would have to reach into a JSword OSGi service to register itself, in much the same way you register a Filter with FilterFactory today (this is a minor point, but I think worth mentioning). One major benefit of having it be a service, though, is that you're talking to an interface managed by the OSGi framework, instead of an instance sitting in a dependent jar.

Losing the RCP dependency means losing some of the job interfaces (e.g. IProgressMonitor). We can replace this with something that's easily adapted to RCP's classes. 

I think we'll need to identify where exactly the JSword jar and Common jar connect to each other, and probably with BibleDesktop's application jars. I created one RCP plugin for these jars because I didn't see a gain in managing the package relationships. Would we want to export/expose all of their packages or should we consider making some packages private (implementation packages, e.g. o.c.j.book.filter.gbf, come to mind)?

>From an Eclipse perspective, we probably want to make these plain Java projects rather than plugin projects. The OSGi implementation used by the plugins is part of the org.eclipse.osgi_*.jar. I'll look into finding a framework-neutral OSGi jar that we can use.

DM Smith <dmsmith555 at yahoo.com> wrote: I mentioned in my last email that using OSGi for plugins would be desirable.

Would someone like to take this on. I'd like to see one or more of these 
prototyped to use OSGi library directly and as indirectly through RCP.

My apologies in advance for how badly this outline will wrap.

Here are the classes in JSword that use a plugin model. (note: using 
abbreviated package names)
We use a Filter to transform from a text string in input language into 
an OSIS xml document.
    Pairs implementation of o.c.j.book.filter.Filter.java to symbolic names.
    o.c.j.book.filter.FilterFactory will provide an instance of the 
requested filter by symbolic name.
    Note: we anticipate the addition of a "TEI" filter.

Installer: (A bit convoluted)
We use an installer to "download" books from a download site.
    Pairs implementations of o.c.j.book.install.InstallerFactory.java to 
symbolic names that mimic specialized protocols.
    o.c.j.book.install.InstallerManager.java will manage Installer 
instances of the requested InstallerFactory by symbolic name.
    Note: o.c.j.book.install.InstallManager.properties is a persistent, 
initial store of download sites. It is not a plugin.
    Note: We anticipate the addition of two more installers:
        A direct download installer which would grab and install a zip 
of a module.
        A local file-system installer which would copy a module from one 
location to the current install location.

Creating an index of a Book, formulating queries, and searching an index 
are a dependent set. We use a plugin model so that we can develop new 
techniques. Currently we only allow for a single set of behavior. While 
there are interdependencies, these are manually managed by the developer 
changing these plugins. If we allowed for more than one kind of index 
this would need to be changed.
    The IndexManager manages the life-cycle of an Index.
    Names the one and only one implementation of IndexManager.
    o.c.j.book.index.IndexManagerFactory.java provides an instance of 
the IndexManager.

    A QueryBuilder parses a string into a Query.
    This property names the one and only implementation of a QueryBuilder.
    An instance of the QueryBuilder is provided by the QueryBuilderFactory.

    A QueryDecorator decorates a string with the requested decoration.
    The purpose is to allow for the programmatic generation of inputs to 
    This property names the one and only implementation of a QueryDecorator.
    QueryDecoratorFactory doles out instances of QueryDecorator.

    A Searcher applies a Query against an Index to return all the hits 
as a Key (which can be a list of Keys).
    This property names the one and only implementation of a Searcher.
    SearcherFactory can be requested for an instance of a Searcher, 
which is not reusable.

Book/Module handling:
    Pairs implementations of BookDriver to a symbolic name, where each 
named BookDriver handles the set of books known to that driver.
    All implemented BookDrivers are registered via Book.autoRegister 
which calls Book.registerDriver, thus acting as a Book factory.
    Note: currently we have 2 BookDrivers:
       SwordBookDriver which describes the Sword modules that JSword 
currently handles (only GenBook is lacking)
       ReadingsBookDriver which describes a daily reading plan.
    Note: We hope to add a driver which will allow for the direct 
importation of OSIS Bibles (and subsequently other kinds of OSIS documents)
    Note: It should be possible to add an ESwordBookDriver, but we won't 
go there.

Conversion of OSIS XML to HTML
o.c.c.xml.Converter.properties (This is messy and should be "fixed")
    Provides a named list of ways to transform XML.
    o.c.j.util.ConverterFactory acts as a factory for Converters named 
"Configurable" (hardcoded)
    o.c.b.util.ConfigurableSwingConverter.java allows for the user to 
pick via options which known xsl the user wishes to use. (This ability 
is turned off since there is only one style provided.)


jsword-devel mailing list
jsword-devel at crosswire.org

Want to start your own business? Learn how on Yahoo! Small Business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/jsword-devel/attachments/20061211/d9582b4e/attachment.html 

More information about the jsword-devel mailing list