The Jakarta Jetspeed development team has released the latest version of the Jetspeed Portal Server, version 1.4 Final Release.
- Search service refactored with pluggable document handlers
- Parameter style jsp tag
- Logging converted from Turbine to Commons + log file viewer portlet. Contributed by Harald Ommang
- Improved portlet skinning capabilities. Contributed by Aurelien Pernoud
- WebClippingPortlet. Contributed by Marco Mari
- MyPages functionality
- Java applet portlet
- BASICAuthIFrame portlet. Contributed by Jacob Kjome
- Implemented portlet icon functionality
- Polish language resource bundle
View the Bug Fixes
in this release.
Go to the JetSpeed home page
This release comes just after JSR 168, the Portlet Specification is final
Is this the RI for JSR 168? If not, can somebody explain how this realted to Pluto (how does it fit in)?
At this point, I believe they are 2 separate codebases.
Functionally, Pluto is a subset of Jetspeed. Pluto is simply a portlet container - write a portlet, and you can run it under Pluto. Pluto is not, however, a portal - Jetspeed is. A JSR-168 compliant portal must contain a portlet container - I would not be surprised to see Pluto incorporated into Jetspeed as its portlet container. Additionally, a portal will usually add a security framework, the ability to aggregate multiple portlets, customization of content (users can choose which portlets they want, and what content appears in them), and skinnability, to name a few of the services they provide.
Note that Jetspeed 1.4 DOES NOT use pluto as its portlet container.
This will only be the case for Jetspeed2.
So actually if you want a portal that uses a portlet container that is a JSR 168 Open Source implementation (still need to get the TCK from Sun to claim compliance) look at ... ok you already know where to look after my article on TSS.
Good point. I figured from the timing of the release that Jetspeed would certainly be JSR-168 compliant, but that doesn't seem to be the case.
Up to this point, my portal experience has been bittersweet. Liferay has a great set of default portlets, decent documentation, and the setup worked well, but anything I tried outside of the default configuration left me bewildered. Furthermore, responsiveness on the forums is notoriously bad. The number of people who have tried Liferay and hit a show-stopper error must be astronomical. There are far too many posts on their "Help" forums with 0 replies - it is very telling.
Jetspeed is Jakarta, and that's a plus in my book, but the database scripts were completely wrong, and the lack of JSR 168 support makes it a wait-and-see for new enterprise deployments at this time.
Exo is the next, and last open-source portal solution I've found to look at. It's on my to-do list, and I'm hoping it can meet our needs. One positive is that I seem to have read that you can deploy portlets in a separate .war, which is something that seems obvious to me, but is lacking in other portals.
True, the eXo platform is the only Open Source portal that allows hot deployment of portlets war...
And this is not the only reason to use it...
I'm sorry about your bad experience with the Liferay forums.
We concentrate on our mailing list more and are quite responsive there. The link is http://sourceforge.net/mailarchive/forum.php?forum_id=8568
and there's about 1500 messages from the past few months that talk about how to customize and install Liferay.
We also redid our deployment for the latest JBoss+Liferay bundle so that the .ear is expanded, this will allow you to incrementally update files without waiting for JBoss to restart.
Furthermore, responsiveness on the forums is notoriously bad. The number of people who have tried Liferay and hit a show-stopper error must be astronomical. There are far too many posts on their "Help" forums with 0 replies - it is very telling
That's strange, I've found Brian very responsive. Today I found two problems with JBoss instructions and he's already fixed those soon after the email arrived. I had the 2.0.0rc3 code base up and running in minutes.