[jsword-devel] feather request: book downloading and index generating api

Zhaojun Li lzj369 at gmail.com
Fri Dec 8 22:51:59 MST 2006


Philip,

I don't konw OSGi good enough either. However, guys in the street tell me it
is cool.

I think a standard ant build to create a plugin jar is good enough for now.
With your effort, I think we are in a good position now.  Since you are
burned out, :) , I can take over your GUI and maintain mine too. After all,
it is not very hard for this part.

Since you did the migration already, Could you share your changes? I mean
overview, why and how.

On 12/9/06, P. R. B. <dysbiote at yahoo.com> wrote:
>
> Another thing to consider is to put the JSword and Common code into a
> basic OSGi bundle / RCP plugin jar and have BibleDesktop run an OSGi
> framework implementation (something like Apache Felix). The Crosswire jars
> would stay independent of RCP, yet RCP developers could treat the jars as
> standard plugins. Some abstraction classes would still need to be made to
> the JSword/Common code for RCP'rs, to reduce the conflicts that Zhaojun and
> I ran into.
>
> I don't know enough about OSGi to say what other pros and cons there are.
>
> As for making BibleDesktop a standard GUI RCP: Yes, you'd be dependent on
> SWT.
>
> Any other thoughts? It seems like we've got some good ideas floating
> around.
>
> ----- Original Message ----
> From: David <lzj369 at gmail.com>
> To: J-Sword Developers Mailing List <jsword-devel at crosswire.org>
> Sent: Friday, December 8, 2006 10:50:14 PM
> Subject: Re: [jsword-devel] feather request: book downloading and index
> generating api
>
> The main advantage for RCP that it hides the low level details from
> business logic. A big plus is cross platform is piece of cake. We can click
> several times to make it run on almost every platform like linux,
> windows,mac ,ppc, you name it. It is native code call from java layer, thus
> very fast.
> The biggest challenge is the size.
>
>  The default size is like 9mb.
>
> Another advantage is update: RCP has built-in update site support. It even
> supports anatomical update! even scheduled update!
>
> Plus, it is de facto standard for JAVA IDE now. and IBM is behind it.
>
> as far as BD gui, it is hard to tell because it depends. My experince
> tells me that it is very easy to mimic the current gui with two views.
> Installation view can be done , I have it done already, it can be shared.
> The other part is main gui: it should be a Form base with a broswer GUI or
> two.
> The preference can be done by using RCP built-in preference api. It is
> very simple. I can share my code by providing a simple tutorial.
>
> BTW, all code are open sourced.
>
> I have different opinion about the classloader. Yes, jsword's class loader
> creates an issue for RCP. However, I do not think removing it is a good
> idea. We can add addition classes or addition methods to jword (Jsword, and
> common) to solve this issue. Maybe is is time to create an standard eclipse
> plugin. I can offer help on this one.
> Next week I will release all the code to a place so everyone can share and
> modify.  The GUI like a clone of WEBSOWRD on crosswire.com
>
> In Christ,
>
> Zhaojun
> On 12/8/06, DM Smith <dmsmith555 at yahoo.com> wrote:
> >
> > Zhaojun and Phillip,
> > I think there is enough interest that it would be good to meld all this
> > into one effort.
> >
> > Phillip, I'm sorry you have burned out. Perhaps if we had collaborated
> > we could have shared the load.
> > Please help me understand the advantages and disadvantages of going to
> > RCP for JSword and Common. And what impact it would have on the BibleDesktop
> > GUI. How portable is RCP? Will it run on all platforms that Java runs? Or is
> > it limited like SWT?
> >
> > I've done a bunch of reading, but have been focusing on adding behavior
> > to what we have. So I have not really experimented too much.
> >
> > In Him
> > DM
> > On Dec 8, 2006, at 9:17 PM, P. R. B. wrote:
> >
> > Hi gang,
> >
> > I ran into the same problem with RCP. I ultimately turned the core
> > JSword libraries (common and jsword -- the parts I was after) into an RCP
> > plug-in that could accommodate the RCP Job class and use plug-ins to extend
> > the installer, filter, and driver (RCP needs to manage class loaders itself,
> > so the class utilities and property files were removed). The key to changing
> > the job code, for me, was to replace JSword-Job calls  with IProgressMonitor
> > calls, and making all calls run in the caller's thread. The IProgressMonitor
> > interface serves essentially the same purpose and the JSword Job class, so
> > the change was fairly straight-forward.
> >
> > I have an example of the changes that I made at the bottom of this
> > e-mail.
> >
> > Off-topic: I hit project burn-out with this endeavor a few weeks back
> > and the fate of the code is undecided (I take project burn-out pretty hard).
> > The JSword plug-in is functional and the RCP application is 100% working. If
> > anyone wants to play with it or is interested in helping me resurrect the
> > thing back to life, please let me know.
> >
> > Thanks,
> > -Phillip
> >
> > --
> >
> > Example changes to convert JSword Job code to use IProgressMonitor (for
> > non-RCP'rs, IProgressMonitor and IStatus are part of the Eclipse/RCP core
> > API):
> >
> > Installer interface:
> >     IStatus install(IProgressMonitor monitor, Book book);
> >
> > HttpSwordInstaller class:
> >     public IStatus install(IProgressMonitor monitor, Book book){
> >         // Is the book already installed? Then nothing to do.
> >         if (Books.installed().getBook(book.getName()) != null)
> >         {
> >             monitor.beginTask(Msg.INSTALLING.toString(book.getName()),
> > 1);
> >             monitor.worked(1);
> >             monitor.done();
> >             return Status.OK_STATUS;
> >         }
> >
> >         final SwordBookMetaData sbmd = (SwordBookMetaData)
> > book.getBookMetaData();
> >         try
> >         {
> >             // the task has as many steps to perform as there are parts
> > to the download
> >             monitor.beginTask(Msg.INSTALLING.toString(book.getName()),
> > (getSize(book) / 4096) + 1);
> >             monitor.subTask(Msg.JOB_INIT.toString());
> >
> >             URL temp = NetUtil.getTemporaryURL("swd", ZIP_SUFFIX);
> > //$NON-NLS-1$
> >
> >             // download the book. Each chunk downloaded contributes to
> > the monitor's work.
> >             download(monitor, directory + '/' + PACKAGE_DIR,
> > sbmd.getInitials() + ZIP_SUFFIX, temp);
> >
> >             // Once the unzipping is started, we need to continue
> >             File dldir = SwordBookPath.getDownloadDir();
> >             if (!monitor.isCanceled())
> >             {
> >                 monitor.subTask (Msg.JOB_CONFIG.toString());
> >                 IOUtil.unpackZip(NetUtil.getAsFile(temp), dldir);
> >                 SwordBookDriver.registerNewBook(sbmd, dldir);
> >             }
> >
> >         }
> >         catch (Exception ex)
> >         {
> >             Reporter.informUser(this, ex);
> >             return new Status(IStatus.ERROR, JswordActivator.PLUGIN_ID,
> > 0, Msg.UNKNOWN_ERROR.toString(), ex);
> >         }
> >         finally
> >         {
> >             monitor.done();
> >         }
> >
> >         return Status.OK_STATUS;
> >
> >
> > ----- Original Message ----
> > From: David < lzj369 at gmail.com>
> > To: J-Sword Developers Mailing List < jsword-devel at crosswire.org>
> > Sent: Friday, December 8, 2006 10:26:01 AM
> > Subject: Re: [jsword-devel] feather request: book downloading and index
> > generating api
> >
> > Hi, DM,
> > If you just want to migrate to SWT, I personally think it does not worth
> > it. SWT just another set of API, like SWING.  However, if you want to
> > migrate to NETBEAN RCP or Eclipse RCP, I will applause your effort. (The
> > application size will be increased by 6-9MB).  For Eclipse RCP, the work is
> > just create veiws and call jword api.
> >
> > The work I am doing is based on Eclipse RCP. Jsword is a base part of
> > it. The plan is to build a p2p system that can enable blog , forum sharing,
> > of course file sharing(  JXTA.)  next year.  It will be a set of plugins.
> >
> > Right now, I am rewriting the system to look like exactly what is on web
> > sword interface. After all, people are familar with web interface.  I ,
> > however did a websword plugin with tomcat embedded(yes, a server on user's
> > desktop).  It is cool. However, due to other considerations, I put it on
> > hold.
> >
> > Since you are interest, I will put the source code to Google code next
> > week.  I tried sourceforge, still does not get approved.  An alternative is
> > I put the code temporily into jwsord SVN, so you can look at it. Again, next
> > week. :)
> >
> >
> >
> > On 12/8/06, DM Smith < dmsmith555 at yahoo.com> wrote:
> > >
> > > We hope to migrate the UI to SWT. So I am very interested in your RCP
> > > work. Is there a place where I can see what you have done. If
> > > possible,
> > > I'd like to minimize your pain of re-integrating the JSword as it
> > > changes.
> > >
> > > David wrote:
> > > > Eclipse RCP platform has its own threading api. Use can choose the
> > > job
> > > > run on backgroud or foreground. I maybe need to double check why the
> > > > process failed. (I believe it is because of threading)
> > > > For book installation, I added two mirror methods to do downloading
> > > > and copying.  It works fine. The only issue is the api and package
> > > > keep changing and I have to compare every time there is a new
> > > release
> > > > and merge the code.
> > > >
> > > > For indexing, I have not made it to work correctly.  I will study
> > > the
> > > > code next week. The basic idea is kick off a background job and call
> > > > jsword api to generate index. No thread for indexing itself is
> > > needed.
> > > >
> > > > For Web sword, the book installation is on server side. Never mind.
> > > > It will not be used for end users. I put it on hold because I have
> > > > several othe plugins need to be done soon.
> > > >
> > > > Zhaojun
> > > >
> > > > On 12/8/06, *DM Smith* < dmsmith555 at yahoo.com
> > > > <mailto:dmsmith555 at yahoo.com>> wrote:
> > > >
> > > >     David wrote:
> > > >     > Hi, DM and fellow developers,
> > > >     >
> > > >     > I am developing web sword(90% done, pure j2ee implementation,
> > > will
> > > >     > help web hosting) and sword on eclipse RCP.  Issues were
> > > raised up
> > > >     > when I try to integrate install book and generate indices. The
> > > code
> > > >     > now has job api build in and also has the reporter to
> > > >     communicate with
> > > >     > user UI.
> > > >     >
> > > >     > In order to accelerate the acceptance of jword library,  the
> > > api for
> > > >     > downloading books and api for index processing need to
> > > seperated
> > > >     from
> > > >     > Job api.
> > > >     I'm not sure I understand the problem.
> > > >
> > > >     The index api (org.crosswire.jsword.index) is independent of the
> > > >     Job and
> > > >     Reporter apis. The Lucene implementation is not.
> > > >     Likewise for the install api ( org.crosswire.jsword.index ) and
> > > the
> > > >     sword
> > > >     implementation.
> > > >
> > > >     Both the Job api and the Reporter api are listener based. If
> > > there
> > > >     is no
> > > >     listener for Job events or Reporter events, then those are not
> > > heard.
> > > >     Any listener of your choosing can be provided or not provided.
> > > It
> > > >     is up
> > > >     to you.
> > > >
> > > >     The purpose of the Job and Reporter apis is to provide
> > > asynchronous
> > > >     communication of a potentially background task thread. For
> > > >     example, you
> > > >     will notice in BibleDesktop that you can download and/or index
> > > >     more than
> > > >     one Book at a time. Each download and index is on its own thread
> > > >     and it
> > > >     communicates back to BibleDesktop asynchronously of its progress
> > > >     or any
> > > >     problems that are encountered.
> > > >
> > > >     In a web environment asynchronous communication of long-lived
> > > >     threads on
> > > >     the server may prove to be a challenge, but it should be
> > > possible.
> > > >
> > > >
> > > >     _______________________________________________
> > > >     jsword-devel mailing list
> > > >     jsword-devel at crosswire.org <mailto: jsword-devel at crosswire.org>
> > > >     http://www.crosswire.org/mailman/listinfo/jsword-devel
> > > >
> > > >
> > > >
> > > ------------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > jsword-devel mailing list
> > > > jsword-devel at crosswire.org
> > > > http://www.crosswire.org/mailman/listinfo/jsword-devel
> > > >
> > >
> > >
> > > _______________________________________________
> > > jsword-devel mailing list
> > > jsword-devel at crosswire.org
> > > http://www.crosswire.org/mailman/listinfo/jsword-devel
> > >
> >
> > _______________________________________________
> > jsword-devel mailing list
> > jsword-devel at crosswire.org
> > http://www.crosswire.org/mailman/listinfo/jsword-devel
> >
> >
> > ------------------------------
> > Check out the all-new Yahoo! Mail beta<http://us.rd.yahoo.com/evt=43257/*http://advision.webevents.yahoo.com/mailbeta>- 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
> >
> >
> >
> > _______________________________________________
> > jsword-devel mailing list
> > jsword-devel at crosswire.org
> > http://www.crosswire.org/mailman/listinfo/jsword-devel
> >
> >
> >
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
>
>
> ------------------------------
> Access over 1 million songs - Yahoo! Music Unlimited.<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yahoo.com/unlimited/>
>
> _______________________________________________
> 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/20061209/01a85655/attachment-0001.html 


More information about the jsword-devel mailing list