portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject Re: Pluto Upgrade
Date Tue, 13 Mar 2007 04:10:02 GMT

Ate Douma wrote:
> David H. DeWolf wrote:
>> Hello Jetspeed!
>> I just wanted to show my face on this list and encourage you guys to 
>> upgrade to pluto 1.1.x.  
> As you already know, that is one of my goals for Jetspeed-2.2.
> My plan is to create a separate playground branch for that so we can 
> investigate and try out the amount of refactoring needed for this 
> without direct interfering with the trunk.

Yup.  That's why I'm hear :)

Unfortunately, In terms of the amount of refactoring, I guarantee that 
it will be significant.

>> There are now two other open source portals embedding this series and 
>> I think we've flushed out a lot of things that will (eventually) help 
>> jetspeed.  uPortal, for example, reports that the pluto significantly 
>> reduced both the complexity and the size of their code base by an 
>> order of magnitude.
>> As with both the uPortal and the Sakai implementations, I don't 
>> anticipate that the pluto team would have thought about *everything* 
>> that you will need.  In fact, I'm hoping that you are much more tied 
>> to use than the other two were,
> Most likely yes. I don't know how uPortal or Sakai handled the complete 
> rewrite of the descriptor-api, but Jetspeed-2 is very much tied to the 
> "old" Pluto 1.0.1  om classes. We actually based and extended most of 
> our persistent portlet registry on that class hierarchy, and seeing 
> Pluto 1.1.x has completely thrown that old model away, I have the 
> suspicion our migration is going to be *very* painful to say the least...

uPortal was actually very similar.  They extended many of those same 
classes, and though migrating won't be fun, I hope you at least give it 
a chance before you give up.  Eric of uPortal hangs out on the pluto 
list.  He may have some advise or ideas on what this will take.

>> and as a result, will have many more requirements which will help 
>> flush pluto out into a more rohbust implementation.  
> I don't mind improving Pluto of course but I just hope if we don't have 
> to rewrite our whole persistent portlet registry from scratch.

Why would you have to do that?  If nothing else, create an adapter.

> As David Taylor already asked: did you ever write some design, 
> guidelines or something how Pluto 1.1.x deviates from Pluto 1.0.x?
> That might give us some useful insight how to proceed.

No, and frankly, I don't plan to. I don't mean to sound crass, but I'd 
much rather spend my time answering direct questions and coding.  I know 
this sucks, but if I were to promise documentation, you'd be utterly 
disappointed because I'll fail to deliver.  The reality is that 1.1 is 
completely different.  IMHO it's useless to try to quantify the changes. 
  This has been discussed over and over on the pluto list for the past 
couple of years.

>> The good new is that I believe that it currently has a solid 
>> foundation in this regard.
> Has uPortal, Sakai or any other portal embedding Pluto based their 
> persistent model on the new Pluto descriptor api and did they face the 
> same migration issue in this respect as us?  If so, than that would be 
> good news indeed.

Yes, uPortal did.  Ping the pluto list and Eric will definitely reply 
with his experience.  He already has for a couple of others that asked. 
  I'm going to forward one thread about this topic to this list.

>>  In addition, not only am I standing by waiting to help enhance pluto 
>> to meet your needs, we have been able to stream line our release 
>> process and are pushing out releases much more frequently (1 every few 
>> weeks to a month).   In fact, Pluto 1.1.1 was just released last week 
>> and I am targeting a new release for 1.1.2 within the next week or two.
>> Please let me know how I can help get you kickstarted!
> I expect to start the separate branch for this sometime this week. I'll 
> ping you as soon as I'm ready for it :)

Okie. . .sounds like a plan.

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

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

View raw message