geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <paulmcma...@gmail.com>
Subject Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
Date Mon, 29 Oct 2007 18:21:31 GMT
On Oct 27, 2007, at 11:32 AM, David Jencks wrote:

>>> 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.
>
> I haven't looked into exactly how the admin console plugins get  
> added to the admin console but if they are geronimo plugins they  
> have already gone through the deployment process and there is no  
> chance for the jetspeed MBE to see them as the deployment machinery  
> is not activated at all when a plugin is installed.

I see your point.   Limiting portal apps to installation via plugin  
would offer an advantage that developers can pick the appropriate  
MBEs at build time, giving them & us (the MBE provider) fine grained  
control over every step in the deployment process.

While using MBEs has proven to be a very successful approach for  
deploying services and enterprise apps in Geronimo I am concerned  
that the lack of any standardization or a specification for deploying  
portal apps could make this difficult and fragile in the case of  
portlets.  My observation has been that deployment into most portals  
(Liferay, Pluto, uPortal, and even Jetspeed itself) is based on the  
concept that the developer creates a standard WAR and uses the  
Portal's runtime or build-time utility for preprocessing it.   Then  
the portal deploys the preprocessed WAR using the app server's  
standard deployment mechanism, or relies on the end user to do this.   
Can/should deployment of portlet into Geronimo be an extension of  
that process?  I have been inclined to follow that approach so far  
but there may be disadvantages I haven't thought of.

BTW, I have started using the term "console extension" instead of  
"console plugin" because adding portlets to the admin console doesn't  
currently require them to be packaged as plugins.    A console  
extension can be installed as a plugin or it could be deployed like  
any other ordinary WAR.   I hope most developers will offer their  
console extensions as plugins because they are easier for end users  
to browse and install.   But I think the latter option (deploying  
console extensions as a WAR) will be important to developers that  
don't want to create plugins for reasons such as the reliance on  
maven to build them, the sensitivity of plugins to Geronimo server  
versions, etc.


Best wishes,
Paul


Mime
View raw message