<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>Phiillip,</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>I really appreciate you looking into this.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>On Dec 17, 2006, at 2:50 PM, P. R. B. wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">Update and questions from the OSGi front.<BR><BR>Additional general information about OSGi services.<BR>A service can be associated with arbitrary key/value properties, and a service can be found by querying against those properties. For example, a Filter service that has a FilterName property of "gbf" can be searched for specifically by adding another query clause to the service filter string. Also, multiple services that implement the same service interface(s) can be retrieved at once. A ServiceFactory object can be used in place of service instances to allow lazy service instantiation.<BR><BR>Links to OSGi coding tutorials: <BR><A href="http://oscar-osgi.sourceforge.net/tutorial/">http://oscar-osgi.sourceforge.net/tutorial/</A><BR>http://www.knopflerfish.org/osgi_service_tutorial.html<BR><BR>Link to OSGi framework javadocs: <BR>http://www2.osgi.org/javadoc/r4/index.html<BR><BR>Proposed changes for the OSGi version of Common:<BR><BR>Name the OSGi project org.crosswire.common according to Eclipse naming conventions and to reduce the chance of name collisions with the bundle in other projects and systems. This would also help us distinguish between the OSGi project and any RCP wrapper project we create for it.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV>So if I understand you correctly, Under incubator, you'd create a folder to hold all the rcp projects, say rcp or jsword-rcp. Under that folder you would have a project named,</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN>org.crosswire.common</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>And under there you would hold the common source.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I don't see a problem with this. There is nothing important in the current project naming convention. With little problem we could rename the existing projects (only the build.xml and Eclipse project files know of the project names)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Currently, we are following the project structure defined by Maven as we were thinking of migrating to using that as a build management tool. The current layout provides the following (and if we can still satisfy it via some other mechanism, I'll be happy)</DIV><DIV>a) Automated build that can be run from the command line on a Linux platform (currently Fedora Core 6) and also invoked within Eclipse. The current build system understands the dependency relationships between projects and ensures that dependencies are processed in the proper order.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>b) Test is separate from the source that it is testing, but the tests are in the same package as the classes they test. We use JUnit for testing and this probably should be preserved. The tests can be run from within the ant build, but currently are turned off. I run them before I check in code. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>c) Resources that drive the application or a part of it but don't have a particular location are homed together in each project in a separate resource directory.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BLOCKQUOTE type="cite"><BR>Convert the Job class to an interface. Methods that use Job (mostly in JSword) will take a Job as a parameter and run in the caller's thread. An RCP wrapper would have an adapter to convert an IProgressMonitor into a Job. This would allow generic OSGi callers and RCP callers to track the job themselves.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV>I was suprised to find that Job was not an interface. It should be. I still think that it is fairly important (i.e. I could be pursuaded otherwise) that the interface should not presume that progress is being monitored.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR><BLOCKQUOTE type="cite"><BR>Logger - This class will wrap a collection of logger services, similar to how Log4J allows multiple appenders. Callers will use the class as usual. <BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>Good. That's what this Logger is meant to do.</DIV><DIV><BR><BLOCKQUOTE type="cite"><BR>Converter - This interface will be moved to a new package to indicate that it is used for services (appears to be an OSGi convention). TransformingSAXEventProviderConverter will not be a service because it's constructor takes a parameter (we can modify this class or the interface later to make it service-friendly). Implementors will register instances along with a name property to simplify retrieval.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>OK.</DIV><DIV><BR><BLOCKQUOTE type="cite"><BR>Proposed changes for the OSGi version of JSword<BR><BR>Filters, Installers, other plugin/service classes and interfaces: These will follow the same principal as Converter above, i.e. move the interfaces to packages to indicate they're service interfaces, register instances with a name property for retrieval. <BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>I'm not sure I understand this. For example, Filter.java is an interface and it already is in a package o.c.j.book.Filter is a package that contains Filter.java and a few support classes. If I understand correctly OSGi obviates the need for FilterFactory.java. Msg.java or something that is equivalent for internationalization is needed.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>We have an effort underway to internationalize into German and Farsi. It would be best to retain as much of that effort as possible. So far they have not gotten to the JSword properties.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR><BLOCKQUOTE type="cite"><BR>Begin removing calls to ClassUtil since the framework's class loaders and service API will reduce the need for and usability of the class. <BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV>I think this is mostly true. One of the primary purposes of this class is to produce useful "debug" messages for developers but presented to users, so they can tell us what the application says the problem is. As long as the purpose is satisfied, I don't think that it matters how.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR><BLOCKQUOTE type="cite"><BR>Eclipse / RCP wrapper plugins:<BR>Do we want to write our own Eclipse / RCP wrapper plugins around the Common and JSword bundles? This would allow us to convert plugin extensions into service objects ourselves, rather than have the RCP application juggle OSGi service metaphors with extension ones. I don't know if we're at the point where it matters, but I thought it would be worth checking.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>I don't have a clue (because of lack of experience/knowledge). My general principle is to: Consider everything, plan for it, but postpone implementation as long as possible and then only implement what is needed.</DIV><DIV><BR><BLOCKQUOTE type="cite"><BR>Vendor bundles:<BR>We'll need a handful of bundles based on 3rd party code. Where's the best place in the incubator for them?<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>Yes!</DIV><DIV><BR><BLOCKQUOTE type="cite"><BR>Versioning:<BR>Do we want the bundle versions to adhere to the jar versions? Keeping them the same makes synchronizing the code much easier, but bundle/plugin updates adhere strongly to the major/minor/service numbering changes, which is important since other bundles can specify which versions they're compatible with. <BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV>So far the points at which we do releases have affected most of our jars. This is especially true with releases that are further apart. I think that it is important for it to be understandable that what can be used together. Having each release revision all jars has been the easiest way to manage this. Also in a jnlp world the signing requirements are that the collection of jars need to be signed by the same signer. I don't think there is a problem with declaring a new version of a jar or a plugin, even if it has not changed one line of code. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>But as long as it can be managed well, I don't really care.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR><BLOCKQUOTE type="cite"><BR>Thanks,<BR>-Phillip<BR><BR><B><I>"P. R. B." <<A href="mailto:dysbiote@yahoo.com">dysbiote@yahoo.com</A>></I></B> wrote:<BLOCKQUOTE class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> DM,<BR><BR>Eclipse 3.1 requires a few more steps to get to OSGi compatibility than Eclipse 3.2, but nothing too painful. There are some OSGi settings that the 3.2 plugin editor can modify that the 3.1 editor can't, but these could always be added in the manifest.mf file directly. Equinox is also apparently built into Eclipse 3.1. I have no clue what the differences are between versions, but it's probably documented on the Equinox site.<BR><BR>Here's a link to the steps to I used to build and test the bundles. Nothing pretty. I glossed over some of the details in the first section regarding bundle dependencies for brevity. Feel free to point out any difficulties you run into following the steps, should you decide to try them, of if you think of something you'd like to see added to the list.<BR><BR><A href="http://paristano.org/public/osgi_instructions.html">http://paristano.org/public/osgi_instructions.html</A><BR><BR>Thanks. =)<BR>-Phillip<BR><BR><B><I>DM Smith <<A href="mailto:dmsmith555@yahoo.com">dmsmith555@yahoo.com</A>></I></B> wrote:<BLOCKQUOTE class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Phillip,<DIV><SPAN class="Apple-tab-span" style="white-space: pre;"> </SPAN>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space: pre;"> </SPAN>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. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space: pre;"> </SPAN>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><SPAN class="Apple-tab-span" style="white-space: pre;"> </SPAN>Keep us posted.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Many Thanks!</DIV><DIV><SPAN class="Apple-tab-span" style="white-space: pre;"> </SPAN>DM</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><DIV><DIV>On Dec 12, 2006, at 11:19 PM, P. R. B. wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">Hi all, <BR><BR>Okay, here's how far I've gotten so far. First, some quick definitions for this message, to avoid confusion:<BR><BR>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.<BR><BR>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. <BR><BR><BR>The executive summary: <BR><BR>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.<BR><BR>The longer version:<BR><BR>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 (<A href="http://www.knopflerfish.org">http://www.knopflerfish.org</A>). 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.<BR><BR>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.<BR><BR>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.<BR><BR>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.<BR><BR>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. <BR><BR>Thanks,<BR>-Phillip<BR><BR><DIV> <BR class="khtml-block-placeholder"></DIV><HR size="1">Check out <A href="http://us.rd.yahoo.com/evt=43257/*http://advision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail beta</A> - Fire up a more powerful email and get things done faster.<DIV style="margin: 0px;">_______________________________________________</DIV><DIV style="margin: 0px;">jsword-devel mailing list</DIV><DIV style="margin: 0px;"><A href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</A></DIV><DIV style="margin: 0px;"><A href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</A></DIV> </BLOCKQUOTE></DIV><BR></DIV>_______________________________________________<BR>jsword-devel mailing list<BR><A href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</A><BR>http://www.crosswire.org/mailman/listinfo/jsword-devel<BR></BLOCKQUOTE><BR><DIV> </DIV><HR size="1">Access over 1 million songs - <A href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.com/unlimited/">Yahoo! Music Unlimited.</A>_______________________________________________<BR>jsword-devel mailing list<BR><A href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</A><BR>http://www.crosswire.org/mailman/listinfo/jsword-devel<BR></BLOCKQUOTE><BR><DIV> <BR class="khtml-block-placeholder"></DIV><HR size="1">Everyone is raving about <A href="http://us.rd.yahoo.com/evt=42297/*http://advision.webevents.yahoo.com/mailbeta">the all-new Yahoo! Mail beta.</A><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">jsword-devel mailing list</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://www.crosswire.org/mailman/listinfo/jsword-devel">http://www.crosswire.org/mailman/listinfo/jsword-devel</A></DIV> </BLOCKQUOTE></DIV><BR></BODY></HTML>