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