Rapha�l Luta wrote:
What I propose are not *complete* JSR168 compliant portlets in the meaning that you would be able to just deploy them...[Discussion moved to [EMAIL PROTECTED]
Ate Douma wrote:
Hi all,
Currently, the struts-portlet framework is within its own subproject. Recently, Roger Ruttiman added PHP and Perl portlet support to J2.
Other web frameworks I expect J2 to support for Portlet development in the (near) future are at least Velocity, JSF and Spring.
I propose to create a new portlet-frameworks subfolder under J2 to group these these framework wrappers/bridges, each as a separate subproject so they can be used independently.
To allow as much independence on J2 itself so portlets based on the bridges can also be deployed on other JSR-168 compliant portals, I also propose that these bridges should not contain any J2 specific code but only use J2 agnostic interfaces. The StrutsPortlet and the PHPPortlet already have such a spi. Jetspeed implementations of these interfaces should of course *not* be part of these subprojects but can go into the commons subproject.
Several common features of these bridges (like the spi of the StrutsPortlet and PHPPortlet which have the same functionality, or url parameter rewriting) should as much possibly be put in a common subproject.
The current o.a.j.portlet.ServletPortlet is also generic enough to be put there.
If I read correctly what you propose, it's actually creating a repository of useful JSR168 compliant portlets that can be used with any
compliant container.
These portlet frameworks allow common web frameworks to be used for portlet *development*. Maybe some only need a little configuration in portlet.xml (as I think goes for the PerlPortlet from Roger Ruttiman) but most will need to be used *in* portlets.
I'm definitely +1 on the idea but I think such a repository would need to drop the reference to Jetspeed so that as many developpers from many different communities within the ASF or outside can join.
+1
+1
Maybe such a project could be called "Portals Commons" and work somewhat like Jakarta Commons, excpet that sub-projects of Portal Commons would only be JSR168 compliant portlet applications.
But, how much time would it take to setup such a new subproject under Portals (cvs, website, access etc)?
I'm not long enough committer that I have the experience nor the knowledge how that is done and who or what is involved.
The consequence of my proposal already requires me to change the package and resource location naming of the Struts Portlet Framework and has therefore negative impact on our own portlet development which is going to gain momentum real soon.
I'm all for putting these in a Portals Commons but don't like to refactor our own portlet code for too often.
If I anticipate the creation of such a new portals commons subproject I propose the following package/resource definitions:
Base package: org.apache.portals.commons.
Then you will get:
org.apache.portals.commons.common
(provides generic features and spi like for struts, php)
org.apache.portals.commons.myfaces
org.apache.portals.commons.perl
org.apache.portals.commons.php
org.apache.portals.commons.spring
org.apache.portals.commons.struts
org.apache.portals.commons.velocity
...For taglib uri specifications: http://portals.apache.org/commons/
The struts portlet taglib then will have as uri: http://portals.apache.org/commons/struts/tags-portlet
Maven groupId: portals-commons Maven artifactId: portals-commons-<framework>-<version>
Then you will get:
/repository/portals-commons/jars portals-commons-common-0.1.jar portals-commons-php-0.1.jar portals-commons-perl-0.1.jar portals-commons-struts-0.2.jar ...
Note: I simplified things by dropping the framework part but that might lead to confusion and/or conflicts (namespace) when the Commons subproject in the future would also supply complete portlet applications and other resources.
I have already started refactoring the Struts Portlet framework (almost done) in anticipation of my original proposal accepted and can perform the above changes very quickly.
But: I don't want to wait on the creation of a new Commons subproject.
Would it be a problem to temporarily store these under a new portals-commons subfolder in the J2 repository (instead of my original proposed portlet-frameworks)? These then can easily be moved once the Commons subproject is ready.
While I agree on the usefulness of the portlets I expect jetspeed 2 (once it is released) will have an impact which will eclipse (pun intended) these :-)
IMO, the usefulness of the Struts Portlet or Perl/PHP Portlet applications way exceeds the scope of Jetspeed and should be promoted
accordingly.
-- Raphael Luta - [EMAIL PROTECTED] Apache Jetspeed - Enterprise Portal in Java http://portals.apache.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
