Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
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
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
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
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
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. 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. 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
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
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. -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 smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
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
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
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 was hoping that the pluto portlet app deployment would work in the same way with an MBE. 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. thanks david jencks Best wishes, Paul On Oct 26, 2007, at 7:37 AM, Donald Woods wrote: Can this plugin coexist with the Pluto Admin portal in 2.1? Now that the Jetspeed plugin has a JetspeedModuleBuilderExtension.java which handles any webmodule with WEB-INF/portlet.xml as its own, how can we deploy Admin portlets to Pluto vs. user portlets to Jetspeed? Or is this meant only as a complete replacement of Pluto for users who want a full featured Portal? -Donald
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
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 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. Best wishes, Paul On Oct 26, 2007, at 7:37 AM, Donald Woods wrote: Can this plugin coexist with the Pluto Admin portal in 2.1? Now that the Jetspeed plugin has a JetspeedModuleBuilderExtension.java which handles any webmodule with WEB-INF/portlet.xml as its own, how can we deploy Admin portlets to Pluto vs. user portlets to Jetspeed? Or is this meant only as a complete replacement of Pluto for users who want a full featured Portal? -Donald
Re: svn commit: r588500 - in /geronimo/sandbox/jetspeed-integration
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
