On Oct 31, 2007, at 11:52 AM, Prasad Kashyap wrote:
On 10/29/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
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.
Isn't that a serious limitation ? We are forcing all portlet app
developers to use maven and c-m-p. Most 3rd party developers would
just want to build and deploy a portlet war and an associated geronimo
plan. If the geronimo plan conveyed which portal and MBE to use, we
don't have to have this limitation.
Yes, I also think it is a serious limitation and I agree with your
position that portlet apps should also be deployable as WARs.
Technically speaking, though, requiring portlet apps to be
predeployed via car-maven-plugin is an option that has some merit
(such as the careful selection of MBEs as described by David) and
IIUC the approach that was being advocated.
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.
If the portal's runtime or built-time utility is preprocessing the WAR
and deploying it to an appserver, then isn't the onus on them to
deploy it accordingly for the appropriate appserver they support ? The
portal can continue to have their own deployment mechanism while we
can have ours, say in the form of plugins. This two-pronged approach
should fill all gaps and cover all types of users.
Yes, again I think that we are in agreement. IMHO the portal vendor
should continue to be responsible for providing the end user
interface for preprocessing the WAR (if necessary), and then handling
deployment of the WAR into the app server or prompting the user to do
it. This approach allows the portal's existing build-time and
runtime deployment utilities to continue working as usual when the
portal is running in Geronimo. But this is a major decision that
will have long term effects wrt portal integration in Geronimo, so
let's continue to look for feedback and direction on this matter.
Best wishes,
Paul
