geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <paulmcma...@gmail.com>
Subject Re: pluto portal for geronimo 2.0
Date Wed, 13 Jun 2007 15:20:54 GMT
On Jun 12, 2007, at 8:23 PM, David Jencks wrote:

> Sure, but if you are planning to use this for the admin console  
> you'll probably need separate modules for jetty and tomcat anyway,  
> so 2 plans is more or less required even if they  are identical.

Not sure I follow you on this.  Do you mean that we might create two  
separate collections of portlets based on which web container is in  
use?  Today the admin console the same collection of portlets built  
from a single codebase for both containers -- the webconatiner  
administration jsps just render differently when running in tomcat  
vs. jetty.  The only thing I know of that's really different between  
the tomcat and jetty admin console modules is their deployment plans,  
and I think those could be consolidated.

Or are there other reasons why you think separate modules might be  
required, perhaps the security configuration?

Whether or not separate modules are needed for the admin console, if  
we want the portal to be extensible by geronimo applications then it  
would be best if they can provide a single extension module that  
works in both containers.  Hopefully the <container-config> technique  
that Jeff pointed out will allow them to accomplish that (it worked  
for me).

> Is pluto 1.2 actually functional as a real portal, or is it just  
> way easier to deploy portlets to than 1.0 was?  My impression was  
> that it was not really intended to be a jetspeed or liferay  
> replacement.

No it does not provide equivalent functionality to jetspeed or  
liferay.  In fact their FAQ says:

> Is Pluto an Enterprise Portal?
>     No, the Pluto project aims to provide a Java Specification  
> compliant Portlet Container. In order to support the container, the  
> Pluto project provides a simple portal, however, this does not  
> provides optional services such as single sign on. If you are  
> looking for an Open Source enterprise Portal implementation, there  
> are several available. Apache Jetspeed is an enterprise portal  
> hosted by the Apache Software Foundation. Sakai and uPortal are  
> both educational portals which utilize Pluto as their container.  
> There are many other open source portals.
http://portals.apache.org/pluto/faq.html

So for an enterprise class portal Geronimo users should be encouraged  
to look into one of those solutions.

For simple a portal application like the admin console, and for  
portlet development and testing purposes I think pluto's portal  
driver provides an ideal lightweight solution.  And technically  
speaking there's nothing that prevents a geronimo user from  
installing multiple portal solutions alongside pluto.

> I've been hoping that now that jetspeed has m2-ized their build we  
> might be able to pursue jetspeed integration again.

As mentioned above pluto doesn't claim to provide an enterprise class  
solution.  It's very lightweight and really intended for simple  
portal apps and for portlet development / testing.   As long as the  
portlets are written against the JSR 168 api they should be portable  
across the portal containers.   So by all means let's continue to  
pursue integration with jetspeed, liferay, etc.  We can put all these  
goodies into sandbox/portals for now and then later decide if we want  
to migrate the useful parts into server/trunk or create a new  
subproject.


Best wishes,
Paul
Mime
View raw message