On Oct 27, 2007, at 6:56 AM, Donald Woods wrote:
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.
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.
thanks
david jencks
-Donald
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
