The Java Plugin Framework (JPF) is an open source, LGPL licensed library that is intended to provide standard plug-in infrastructure to existing or new Java projects. It helps improve modularity and extensibility of Java systems and decrease their support and maintenance cost. The framework implements the runtime engine that dynamically discovers and runs plug-ins. A JPF plug-in is a structured component that describes itself to the framework using a manifest file. The framework maintains a registry of available plug-ins and the function they provide (via extension points and extensions). To simplify deployment and distribution, a plug-in may be packaged as a "single ZIP file" that will be unpacked at runtime. The JPF package includes a core runtime library, an application boot utility and set of Ant tasks to automate common development routines (plug-in versioning, packaging, documenting, integrity checks etc.) The major changes since the previous release are: * JPF is now ported to Java 5. Two separate flavors of library are now available. * Directory-based Ant tasks in the JPF-Tools library now support nested tags like many other standard Ant tasks. * Fixed problems with file names and URL's that contain non-ASCII characters. * Improved handling of "reverse lookup" plug-in dependencies. * Added jpf-path Ant task to JPF-Tools. It helps to automatically compose plug-in classpath for using in various tasks like java, javac... * Fixed potential deadlock situation in StandardPluginClassLoader. Visit project home page at http://jpf.sourceforge.net for further details, documentation and tutorial.
- Posted by: Dmitry Alex
- Posted on: March 07 2007 10:43 EST
- How is this related to JAM by Edmon Begoli on March 07 2007 12:34 EST
- Knopflerfish OSGi by John Shuster on March 07 2007 12:45 EST
- Jpf, a lightweight osgi by John Slave on March 07 2007 15:57 EST
- Re: Java Plugin Framework 1.0.1 and 1.5.0 Released by Patrick Santana on March 08 2007 03:03 EST
- JPF in use by Kevin Francis on March 08 2007 10:59 EST
- Where does it fit in? by John Shuster on March 08 2007 11:10 EST
My immediate question is how will this effort play with JAM - Java Module System. Long awaited replacement for jar system that is to be included in Java 7, and that as far as I can tell looks identical to this effort. Thank you, Edmon
I'm currently using Knopflerfish, what are a few good reasons to switch to JPF?
I have not tried jpf before, but i can say that with osgi, maybe this framework is less useful than before. Can we consider jpf a sort of lightweight osgi? Tobia
I'm not familiar with OSGi very well and thus can't give you detailed comparison between JPF and some OSGi implementation like Knopflerfish. I think JPF can be considered as lightweight, simple but feature reach alternative to OSGi. I don't think there is much functionality specified in OSGi but not implemented in JPF. The only big difference is that JPF is not a "big standard" with "huge specification" but simply separate effort implemented as compact, efficient and easy to use library. //Dmitry
I worked with jpf 6 months ago. It was the old version, but even so, it was stable and with good benefits: - Easily integration - Good documentation - Good example I used in a swing application, but never in other solution. Did anybody try? Patrick
We have successfully used JPF in a production middleware deployment for over a year now. OSGI didn't seem ready and I wanted a quick and simple way to deploy additional functionality into my application to meet ever changing requirements without requiring a complete new release every few weeks. Combined with spring and xfire can instantly hot deploy web services that can use the core functionality of the middleware, by accessing existing spring beans without having to suffer any downtime. The modular approach has also proved useful as a way of segmenting work, a developer can work on a plugin to add extra functionality almost completely independently of the rest of the team. It is also quite simple to migrate the code from the plugin into the core project at a later stage. In the long term I see OSGI as the future, especially as the Spring team are heading that way. However JPF is both lightweight and very easy to integrate now! Kevin
With respect, I don't see a need for something similar to Eclipse RCP but not compatible with it. I evaluated Eclipse RCP but chose the NetBeans Platform instead because it offered a good/proven plugin framework, and more importantly, because I would be able to use all my old Swing code directly and not rewrite it using SWT. So, I already know why not to use Eclispe RCP, but would be interested in when I might want to use JPF instead of NetBeans Platform.