geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: pluto portal for geronimo 2.0
Date Wed, 13 Jun 2007 16:36:26 GMT

On Jun 13, 2007, at 8:20 AM, Paul McMahan wrote:

> 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).

module == car file (or plugin), i.e. "pre-deployed" application for  
javaee apps, and you certainly can't run the same web "module" in  
both the jetty and tomcat integrations.  So, unless you are proposing  
a really big redesign of what is in a module for a web app, you're  
going to need separate modules for pluto on jetty and tomcat, the  
base console on jetty and tomcat, each bit of additional console on  
jetty and tomcat....

It's quite possible for the plans for the jetty and tomcat versions  
to be identical (as long as the environment element is added by the  
car plugin), but you still get 2 modules.

thanks
david jencks

>
>> 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