portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Embeddable Pluto 2.0 container for Jetspeed-2
Date Fri, 15 Feb 2008 13:24:51 GMT
Hi Chuck,

Thanks for the clear and positive response.

Like maybe uPortal, it looks like Sakai doesn't need or use as much integration and extendability
from the pluto container as Jetspeed depends upon.
And I fully understand and support the much easier integration the new Pluto 1.1.x architecture
has delivered.

It is not our intention to make it much harder than that for sure, but with the many enhancements
for JSR-286 some changes will indeed be needed at your side 
too for upgrading to Pluto 2.0

We'll do our best to maintain as much of the current integration support, just make it possible
and easier to also integrate on the level we need for Jetspeed.
Any insight and opinion you might have on that while we lay out our plans will be much appreciated!



csev wrote:
> Ate,
> 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 with.
> 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 changes.
> 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.
> [Snip]

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

View raw message