geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
Date Sat, 27 Oct 2007 13:56:04 GMT

Paul McMahan wrote:
> On Oct 26, 2007, at 12:55 PM, David Jencks wrote:
>> On Oct 26, 2007, at 9:34 AM, Paul McMahan wrote:
>>> This jetspeed integration is coming along nicely!  Very promising work.
>>> Instead of introducing a MBE that automatically configures the webapp 
>>> for jetspeed based on the presence of WEB-INF/portlet.xml can we look 
>>> into allowing jetspeed to handle its own deployment via placement in 
>>> its hot deploy directory?   When a war is placed in that directory 
>>> jetspeed processes the portlets internally and then handles deploying 
>>> the war to the app server.   i.e. the portal recognizes the WAR as a 
>>> special kind of app and handles the extra deployment steps, not the 
>>> application server.
>> I think that what Prasad is doing is a better way :-) (which is why I 
>> suggested it).  How would a portlet app plugin work with hot deploy?  
>> imho magic hot deploy directories are really out of line with the 
>> whole geronimo modularity philosophy and I would support removing the 
>> hot deploy functionality we have (well, I know that wont happen, but 
>> I'd still support it).
> I really didn't mean to focus on the issue of hot vs. cold deployment.   
> I'm mainly wondering whether or not, in general, Geronimo should try to 
> encapsulate or otherwise replace Jetspeed's deployment functionality.  
> In addition to hot deploy, Jetspeed also provides a pretty complete 
> maven plugin for managing the portal and deploying portlet 
> applications.   I bet it also provides some type of admin UI for 
> deploying portlet applications.
> As a Jetspeed user I would expect the existing deployment mechanisms to 
> all continue working in Geronimo.  As a Geronimo developer I would like 
> to take advantage of Jetspeed's deployment functionality as much as 
> possible and avoid sensitivities to changes in their architecture going 
> forward.  Utilizing Jetspeed's hot deploy directory is only one idea for 
> how to accomplish these goals, maybe not the best one.  OTOH, using a 
> MBE to subvert Jetspeed's normal deployment processes seems contrary to 
> those goals.  But maybe I am misunderstanding how you suggested to 
> implement this.
>> I was hoping that the pluto portlet app deployment would work in the 
>> same way with an MBE.
> While the portlet spec is pretty complete for application design there 
> currently is no specification for deployment within a portal.  In the 
> absence of a spec Pluto implemented deployment in a pretty clever way 
> that is heavily based on standard webapp deployment and therefore very 
> portable across servlet containers without extra configuration.  So an 
> MBE for Pluto isn't necessarily required, but I can see where a MBE for 
> translating portlet.xml entries into web.xml might be helpful 
> (GERONIMO-3252).   Meanwhile there is a Maven plugin for that.
>>> I have a hunch that trying reverse that paradigm or somehow wrapper 
>>> the deployment responsibilities of jetspeed from within an MBE could 
>>> prove to be confusing to jetspeed users, difficult to implement 
>>> correctly, and very sensitive to the jetspeed version.   And like 
>>> Donald pointed out it would interfere with other portal apps that 
>>> might be deployed in Geronimo like Liferay, uPortal, Pluto (the admin 
>>> console), etc.
>> I think we should look into selecting the portal to deploy to based on 
>> something in the geronimo plan if we really need to support multiple 
>> portals running at once.  If we don't, building a portlet app into a 
>> plugin for a specific portal could be handled by specifying the 
>> desired portal MBE car in the plugin's pom.
> The admin console needs to be lightweight and portable so it is based on 
> Pluto.  The Jetspeed MBE (as currently designed) would interfere with 
> the deployment of admin console extensions.  Adding something to the 
> Geronimo plan to activate the Jetspeed MBE instead of just looking for a 
> WEB-INF/portlet.xml sounds like a reasonable solution.   Let's pursue 
> that approach.

+1 as I see many situations where the Pluto Admin Console will still be 
used even when Jetspeed or Liferay are installed.


> Maybe it's unavoidable, but if possible I hope we can avoid creating 
> plugins that are sensitive to the Portal vendor.   e.g. for one portal 
> app I hope we don't require four plugins:
> myapp-jetty-jetspeed
> myapp-jetty-pluto
> myapp-tomcat-jetspeed
> myapp-tomcat-pluto
> Best wishes,
> Paul

View raw message