portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From csev <c...@umich.edu>
Subject Re: Embeddable Pluto 2.0 container for Jetspeed-2
Date Thu, 14 Feb 2008 01:47:15 GMT

I just wanted to offer some general comments as a consumer of the  
Pluto 1.1 release - which provides Sakai its JSR-168 support.  Sakai  
is not a portal - it is a learning management system with basic  
JSR-168 support as a plugin.  So Sakai makes pretty simple demands on  
Pluto 1.1.

I would never have been able to find the time to de-construct Pluto  
1.0 for use in Sakai.  On the other hand, Pluto 1.1 is amazing to work  

We upgrade our version of Pluto 1.1 by simply replacing jar files.   
Pluto 1.0 could never have done that under any circumstances.

That said, the SPI is not perfect and will likely never be  
"perfect".   Each integration that I participated in had the effect of  
evolving and improving the SPI.

Sakai did not stress Pluto features so all Sakai needed from Pluto was  
a bit of re-factoring of the source tree to get the right things in  
jars (apis in an Api jar), implementation in implementation jars, and  
non-essential stuff somewhere else.

uPortal is a more functional portal than Sakai and needed to extend  
the SPI to make things work.  So we got together and jointly figured  
out what the SPI needs were from uPortal's perspective and made the  

There were tiny incompatible changes that caused Sakai to make slight  
changes - because we were kind of working together these changes were  
easily applied to Sakai - I used Sakai to QA several of the minor  
releases of Pluto.

Now of course the SPI will change yet again in 2.0 and I fully expect  
it.  Because we are using the jars, Sakai will have a solid 168  
implementation as long as we like without being affected by  
improvements in Pluto 2.0 and beyond.

I fully expect that a chunk of work will be needed on my part in Sakai  
to make it into Pluto 2.0 - Some of this might be simply because of  
JSR-286 and some of the work might be simply changing the SPI  
interface to meet the needs of Jetspeed.

So my feeling is that if it is Jetspeed's "turn" to grab Pluto 2.0 -  
you should feel OK if the SPI needs to change a bit - Jetspeed will  
have use cases beyond what the SPI supports - so the SPI evolves.   
That is what will make Pluto 2.0 really awesome and make Sakai's job  
of using Pluto 2.0 really easy because you will have done the "hard  
work" :)

Don't worry about us laggards - we can stick with what we have  
trivially or we can catch-up if we want.  Either way we will certainly  
benefit from the improvements that the Jetspeed work causes in the SPI.

Charles Severance
Unviersity of Michigan

> Ate Douma wrote:
>> Dear committers, community,
>> Jetspeed-2 currently still uses Pluto 1.0.1 as its JSR-168  
>> container, but we want and need to upgrade and migrate to the  
>> latest Pluto container under
>> development, aka the not yet released Pluto 2.0 targeted as the  
>> JSR-286 RI.
>> This however is currently impossible to do because of the  
>> architectural changes Pluto underwent from version 1.0.x to 1.1.x.
>> Technically, viewed from the POV of an easy to embed container for  
>> the Pluto Portal Driver, or environments which only need the out-of- 
>> the-box features
>> provided, these architectural changes have resulted in a much  
>> simpler and easier to understand and maintain model and API, and as  
>> such these changes were great!
>> But... for a portal like Jetspeed-2, which provides a much enhanced  
>> usage and feature list *on container level*, these architectural  
>> changes have, simply put,
>> completely broken with the functional and technical "contract"  
>> provided by Pluto 1.0.x and as such make it now impossible for us  
>> to migrate to the current Pluto
>> container.


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message