[jsword-devel] OSGi plugin opportunity

[DM Smith]

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)
Filter:
We use a Filter to transform from a text string in input language into 
an OSIS xml document.
o.c.j.book.filter.Filter.properties
    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.
o.c.j.book.install.InstallerFactory.properties
    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.

Index/Query/Search:
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.
o.c.j.book.index.IndexManager.properties
    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.

o.c.j.index.query.QueryBuilder.properties
    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.

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

o.c.j.index.search.Searcher.properties
    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:
o.c.j.book.BookDriver.properties
    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.)