The Holy Java

Building the right thing, building it right, fast

Archive for January, 2009

Are portlets dead? JSR168 and JSR286 versus reality.

Posted by Jakub Holý on January 24, 2009

Eric Spiegelberg, an experienced JEE and portlet developer, evaluates in his article JSR-286: The Edge of Irrelevance the changes brought to the portlet community by the "new" JSR 286 and comes to the sad conclusion that the portlet technology has missed its chance and is declining in interest and momentum and JSR 286 won’t change that. Only rarely do the benefits of this technology outweigh the additional complexity, restricted programming model, and other drawbacks. He explains his opinions and gives reasons for them pretty well and I can only agree.

Some of the points we can make here are:

  • The specification, when finally released, is already outdated. JSR168 needed nearly two years to reach the final release in Oct 2003, JSR286 released in Jan 2008 over two years. Add the time needed by portal vendors to implement it and to remove initial bugs and when you finally get to use it in production it lags like three years behind the present world. As Eric puts it: "Reading between the lines, this means that the stated primary goal
    of the recently released JSR-286 is to align itself with the latest
    and greatest Enterprise Java technology of 2003.
    "
  • Portlet developers are 2nd class citizens, all the progress goes on in the web application space and they always have to wait for the "goodies" like JSF, Ajax, GWT, and when they finally get them – maybe after a year or years of delay – their integration into portlets/portals is usually at least flawed.
  • There is a portlet specification but no portal specification. If you want to build nontrivial (multi)portlet applications you will usually need to use your vendor’s legacy portal API to do necessary things otherwise not possible, loosing the already uncertain benefit of portability.
  • Portlets are more difficult to learn and develop and a developer is more restricted than in a standalone web application. Eric writes: "Professional hands-on experience along with the above research
    led me to the conclusion that the portal architecture lacks
    enough technical advantages and distinguishing features to warrant
    an increase in acceptance. In practice, few applications can
    constrain themselves to the isolated and disparate functionality of
    portlets, and relinquishing this degree of architectural control is
    unrealistic in enterprise-level software.
    "
  • Interest in portlets is clearly declining. As Eric finds out, "18 out of
    24 (75 percent) organizations that officially supported JSR-168 in
    2003 do not officially support JSR-286 today
    ".

It’s a pity that portals and portlets aren’t easier to use and haven’t made it into the mainstream, the abilities of content aggregation, personalization, uniform security etc. are promising and as we can see in the rise of personal mashups like iGoogle, the fundamental ideas behind portals are still valid and extremely attractive. I hope that some mashup technology will soon provide a viable, light-weight alternative to portals.

For the sake of completness I should say that I’m currently working on "portletization" of an application and that I spent some time on a JSR 168 portlet for WebSphere project.

Posted in Portlets | Comments Off

Eclipse 3.4: New Update Manager and broken Extension Locations

Posted by Jakub Holý on January 21, 2009

In Eclipse prior to 3.4 you could have a number of external "Extension Locations" for plugins/features you didn’t want in the Eclipse installation directory or that you wanted to share among multiple Eclipse installations. In the Update Manager wizard you could have even selected that you want a plugin installed into a particular extension location. Since Eclipse 3.4 (Ganymede) this isn’t possible anymore.

Problem 1: Links to the external Extension Locations are ignored

Prior to 3.4 you could have directories with plugins and features (extension locations) outside of the Eclipse installation directory ($ECLIPSE_HOME). To let Eclipse know about them you created a file in the directory $ECLIPSE_HOME/links/ containing the text path=/path/to/your/extension/location. Unfortunately Eclipse 3.4 ignores these links. But nothing is lost – move them into the new directory $ECLIPSE_HOME/dropins/ .

Actually you don’t need to have only link files in the dropins directory, you can have there individual packed (.jar) or unpacked plugins or complete extension locations (eclipse/…) either directly under dropins/ or in some subdirectory, e.g. dropins/jboss-tools/eclipse/… .

Problem 2: The new update manager doesn’t let me select where to install plugins

The new plugins management (also known as provisioning system) installation wizard doesn’t let you select where to install the downloaded plugins. It should support something called Bundle pools, that is shared plugin installation folders that can be used by multiple installations of Eclipse but the current user interface doesn’t provide any such options and it also may not be exactly what you need.

If you don’t want to simly forget about installing plugins outside of Eclipse itself, there is a solution – you may re-enable the old Update Manager and proceed as you’re used to. To enable the Update Manager go to Window > Preferences > General > Capablilities and check Classic Update. If you don’t see the option Capabilities (e.g. if you’ve the Java EE Eclipse package) then you can:

1. Either Open the Help window and search for “Manage configuration”, then select ” Enabling, disabling, and uninstalling features”. The help window gives a link to “Help > Software Updates > Manage Configuration.” (by Ronan);

2. Or install Eclipse SDK and restart Eclipse.

Mum, why did all this happen?

All this happened because the old plugin management stuff was replaced by a more clever and capable new provisioning system Equinox/p2. I’d recommend you to read its Getting Started guide. You can learn there about the new directories dropins/ and p2/, about Bundle Pooling (sharing of plugins among Eclipses) and other features.

Posted in eclipse | Comments Off