JBoss Portal and Alfresco

I recently delved into JBoss Portal to put together a demo for a client. I started with JBoss Portal 2.2.1 without Alfresco just to get my feet wet. I was a bit underwhelmed. The documentation was spotty, which I expected. The admin UI was clunky at best and wholely non-functional in some instances (here’s a tip: stick to the XML descriptors and avoid the UI for now).

The bigger problem for my immediate need was that the out-of-the-box CMSPortlet instance couldn’t be easily customized through either XML or the admin interface to show anything but the default content stored in the embedded jackrabbit (JCR/JSR-170) repository. The problem was that the URL was configured as an initialization parameter instead of a portlet preference. To fix that I snagged the updated CMSPortlet from the 2.4.0 Alpha release and deployed it to my 2.2.1 instance which worked great.

My next source of frustration was the JBoss-Alfresco bundle. I didn’t know exactly what was going to be included in the bundled instance of JBoss Portal and Alfresco–in hindsight my expectations were set too high. What I was hoping for was that Alfresco would be configured as the replacement JCR repository for JBoss Portal and that there would be a set of useful portlets that exposed the Alfresco repository to portal users. At a bare minimum I would have expected an Alfresco search portlet and a trimmed down “spaces” portlet.

Instead, what’s included is a single “Alfresco Client” portlet that essentially wraps the entire Alfresco UI in a single portlet. The embedded jackrabbit repository still exists and can be used with the CMSPortlet, but Alfresco isn’t configured out-of-the-box to be used as the content repository for JBoss portal.

These annoyances can obviously be addressed with code. And because JBoss and Alfresco leverage open standards, that code will be easier to write and maintain. I was just hoping that the bundle would have been more tightly integrated. (In the immediate-term I was hoping for a more powerful demo with less sweat equity).

As a side note it makes me wonder: Does Alfresco already have these portlets (and other similar types of value-added code) in-house but not easily accessible (or accessible at all) by the community or do they not exist?

This really illustrates the need for services firms to help clients take open source components the “last mile” by adding glue-code, implementing useful add-ons (portlets, integrations, etc.), and beefing up documentation, all of which could and should be injected back into the community in some form or fashion.