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]
