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!
Regards,
Ate
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]
