JPF 0.6 has been released. JPF is a runtime engine that dynamically discovers and runs plug-ins that is intended to provide standard plug-in infrastructure to projects.

Major changes for this release are:

• Added utility methods to PluginRegistry and PluginDescriptor interfaces that allow simplify checking availability of various plug-in elements.
• Implemented basic Framework localization. All locale sensitive strings are now externalized.
• Revised API exceptions policy and introduced a number of JPF specific exceptions.
• Added new type ("resource") to extension point parameter definition.
• Added optional "version" attribute into "library" manifest tag and implemented corresponding method in the API.
• Significantly reworked and improved plug-ins archive Tool.
• Now PluginManager uses default (or no-arguments) constructor to instantiate Plugin class. Old two-arguments constructor is deprecated and will be removed before 1.0 release.

Visit project home page at http://jpf.sourceforge.net for further details, documentation, demo application and tutorial.

It's a good idea indeed, but Eclipse exists and you can using eclipse core and have kind of application, including SWING, web or no UI.

rephase: It's a good idea indeed, but Eclipse exists and you can with the "eclipse core" have any kind of application, including SWING, web or no UI. why?

I'm not sure that it is possible to use "eclipse core" as you've described :| I think only SWT/Swing based apps "available" and they should be based on Eclipse RCP, which is quite fat (several MBytes).

//Dmitry

I'm not sure that it is possible to use "eclipse core" as you've described :| I think only SWT/Swing based apps "available" and they should be based on Eclipse RCP, which is quite fat (several MBytes).//Dmitry

What do you mean "not sure"?
The authors seem to have went through all this trouble without getting a solid idea of what's going on in this space.
Here's a decent overview of OSGi and Eclipse, as well as other projects in the OSGi space.

Here's a decent overview of OSGi and Eclipse, as well as other projects in the OSGi space.

FYI, there are OSGi implementations outside Eclipse.<br/>
For example, see OSCAR from ObjectWeb. It could be a base for plugin-oriented development.

Dominique

FYI, there are OSGi implementations outside Eclipse.<br/>For example, see OSCAR from ObjectWeb

...or Knopflerfish, which even has an Eclipse plug-in ;)

You can definitely use the Eclipse core to build a non-GUI application (I've done it). The RCP defines an extension point for a basic application "entry point" (in other words, a "main" method). The GUI stuff comes in at a higher level that you can completely disregard.

What you get is an extremely flexible and well-thought-out plugin system that's ideal for building a modular app. (I never counted the size in bytes, but it's smaller than if you include SWT.) You also get some baggage along with it -- e.g., an Eclipse-defined URLStreamHandlerFactory that you can't do anything about.

Hi Ed,

Can you please share your knowledge of how to use eclipse's core? (Is it for 3.1?)

Thanx,
Ittay

+1

A description of practical first steps towards using Eclipse Core for modular J2EE web-application development would be very helpful, I think, for many of us.

thanks
Johan

Does this project have anything to due with a JSR currently in development? The name seems to imply a Java standard I haven't been able to reference.

It's not that a standard Java plugin framework wouldn't be a good thing (or at least useful to some). Even a non-standard plugin framework has uses.

One does need to be careful when naming a project though, as a Java standard and someone's home grown project are very different things. There was even a time where Sun would come after you for names like Java Invaders - space invaders clone written in Java. They were a bit paranoid back then, but it was to prevent confusion like this.

Of course, for the love Gosling, if this is related to a JSR, please point me to it (and update the jpf SF site).

-Jim

Does this project have anything to due with a JSR currently in development?

from the technical whitepaper on osgi.org:

It was therefore decided to develop additional specifications in the OSGi Alliance together with the Java Community Process (JSR 232) to fully match the requirements of the mobile phone manufacturers, operators and enterprises.

here the URL to the technical whitepaper for OSGI. What is cool is that Eclipse has the same kernel as the newest generation of mobile phones and even BMW software;

Is this a RI or pre-release for JSR 232? JSR 232 seems to be targeted towards the mobile market. While there may indeed be a module component to JSR 232, but I wouldn't call 232 the "Java Plugin Framework" spec.

Is this project affiliated with the Sun JCP and a current JSR (i.e. is this SF project the breading grounds for a JSR RI)? Are the JPF developers part of any JSR expert group?

I'm developer of the JPF and can tell you that currently project doesn't related to any JSR. This is a "standalone" development effort for a moment.

//Dmitry

Can someone tell me how the JPF relates to all the other IoC-Frameworks? Whats the advantage over let's say HiveMind with the Interceptor-, Config, and all the other features?

- Stefan

I think JPF can be named as "IoC microkernel" - the very basic API to help making modular and extendible applications or more powerful and reach frameworks.

//Dmitry