Whoa ! Somehow this thread never showed up on my radar screen. Comments inline -
Cheers Prasad. 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. > > 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 > >
