geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <>
Subject Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
Date Wed, 31 Oct 2007 15:52:39 GMT
Whoa ! Somehow this thread never showed up on my radar screen.

Comments inline -


On 10/29/07, Paul McMahan <> 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.

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

> 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

View raw message