JPF vs. Striped-Eclipse

mehdi_cit
2005-10-01
2013-05-02
  • mehdi_cit

    mehdi_cit - 2005-10-01

    Hello Dmitry, and everyone else :).
    I stumbled yesterday on your FrameWork. I cannot really comment on it, but at least it seems nice.
    Actualy I's looking for some FrameWork like yours and was thinking of using the core/runtime/OSGi of Eclipse to achieve something similar. Something like Eclipse RCP without the UI.
    Is JPF something similar to the above, and how does it compare to Eclipse RPC (beside the fact that it has no UI).
    rom using Eclipse, I noticed that its system doesn't support hot-loading (you have to restart the application to trigger the newly installed plugins). However JPF seems to support hot-loading.
    could you care to comment. The more info you provide the better ;). Help make up my mind.
    Thanks in advance.
    Keep up the good work.

     
    • Dmitry Olshansky

      Generally speaking, "Eclipse plug-in framework" and JPF are very close functionally. The JPF was inspired by Eclipse (it's 2.x version XML plug-ins infrastructure, before migration to OSGi). Both approaches are based on plug-ins, extension points and extensions metaphor. Both frameworks have kind of "registry" and "runtime".

      It is hard to compare JPF with "striped Eclipse RCP" in details since I never saw it :) Give me an URL where I can get it and I'll try to give you a comparison table. As I know, "Eclipse RCP without UI" doesn't officially supported for the moment but it seems they are working in this direction.

      As for the current situation, the most significant advantage of Eclipse is it's following to OSGi standard. For some developers this might be very important.

      JPF doesn't follow to OSGi (at least now :). But I think that the major advantage of JPF is it's simplicity and flexibility. This is clear from the Framework API - it is built completely on abstract classes and interfaces.

      Regarding the "hot deploy of plug-ins" feature. It is supported by JPF and, as I know, it should be supported by Eclipse (as it is part of OSGi specification).

      //Dmitry

       
    • Nobody/Anonymous

      Thx Dmitry,
      You are right, Eclipse RCP seems to support hot-loading; At least it is supposed to.
      As for "Striped Eclipse RCP"; it's just a description. I don't know whether there exists such project. Mayeb it's not that difficult to just take Eclipse RCP and remove all .ui stuff and any refferences to them (probably not, but.. maybe).
      When I read about JPF I just asked my self in what ways is it different from Eclipse-RCP.Other than that it doesn't support/ENFORCE the use of any particular UI.
      OSGi would be cool, but it's not a must for me (maybe it should).
      What counts most for me it to build something as easy to extend as possible. Not only technically but also "politically". Meaning that my program's plugins-developement-process should be similar  to "main stream" "conventional" plugin development.
      Eclipse Plugin Developement is well known, documented, comes with a set of developement tools and with a large pool of experiecned programmers. One might argue that sticking to something as wide spread and leveraging its "eco-system" would be the right "strategic" move.
      I haven't tried anything yet. I'm just investigating the possibilities.
      From one hand Eclipse is well known, "tool"-ed and most importantly has THE Eclipse stamp.
      From the other hand JPF seems to be more light weight while it still mirrors to a large extent Eclipse concepts. And for some strange reason, my "heart" is more inclined towards using JPF -:).
      I'm thinking of making a desktop application that should run under any UI (even from console), and that could load new plugins without shuting down.
      Possibly, the "main loop" should be run as a small server/service that accepts "high level" requests from different programs and/or different UI and serve them.
      You can think of it as an experimental solution to reducing not code duplication whithin a single application, but reducing functionality duplication whithin a single machine or Lan. Some sort of hiegh level OS. Or a small humble sibling of existing web-services implementations. 
      Well... I hope you got the idea.
      I'll greatly appreciate any comments or info.
      Cheers.

       
    • Dmitry Olshansky

      I'm agree with you that Eclipse has excellent tooling support to create plug-ins for it's "eco-system". But don't you think that you'll loose all that benefits "striping" Eclipse to make it "headless" and "lightweight"?

      The Eclipse eco-system and it's power is not in great plug-in engine that lies in basis, but rather in rich plug-ins set that do forms that eco-system. All those "Workbench", "SWT", "JFace", "Help" plug-ins forms the UI-centric vision on how to build desktop applications in "Eclipse style".

      If you are going to create your own set of plug-ins that will form another "universe", you may seamless forget about Eclipse as it's strength in it's own "universe". In such "scratch" situation, I think that JPF is better choice as it is designed from the very beginning to be used as pure "plug-in framework" but not a "plug-ins eco-system".

      //Dmitry

       
    • Nobody/Anonymous

      Thx Dmitry.
      You do make good points.
      I'll have to sleep on it for some time. Hopefully I'll see better in few months (I'll be doing some other things).
      Cheers.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks