Scott T. Weaver wrote:
I REALLY don't care for the commons moniker, it is so overused. I would prefer org.apache.portals.portlet.framework.Actually, I don't either :-)
I just accommodated for the name (Commons) of the new Portals subproject Rapha�l suggested.
Let me improve on the proposal then as such:
- temp J2 subfolder
portals-portlet-framework
- base package:
org.apache.portals.portlet.framework.
- base uri for taglibs specifications:
http://portals.apache.org/portlet/framework/
Example:
http://portals.apache.org/portlet/framework/struts/tags-portlet
- Maven groupId:
jetspeed2
- Maven artifactId:
portals-portlet-framework-<framework>-<version>
Example:
portals-portlet-framework-struts-0.2.jarNote: I replaced the portals-commons as the maven groupId to jetspeed2 again. The maven attributes are not that important for now and can be changed if needed when/if we get a new Portals subproject.
But, the base uri for taglibs is kinda important because if that changes all our jsp's have to be changed for that :-(
If this is ok I will update my changes and commit them as such.
Regards, Ate
Ate Douma wrote:
Scott T. Weaver wrote:
Great idea! +1
Thanks.
I would also like to get additional support for the modified proposal I made yesterday in response to the comments made by Rapha�l Luta concerning moving the proposed framework functionality to a new Portals subproject.
That proposal is now done in the general at portals.apache.org list but I also send my responses back to this list (see a few messages before this one).
In particular, I would very much checkin the refactoring I already did for the struts-portlet to be able to get on with my own projects which depend on it.
In short my proposal is (and I already implemented it as such):
- storing the new frameworks temporarily in the J2 cvs repository under folder portals-commons awaiting approval of the portals PMC for a new Commons subproject.
- base package:
org.apache.portals.commons.
- base uri for taglibs specifications:
http://portals.apache.org/commons/
- Maven groupId:
portals-commons
- Maven artifactId:
portals-commons-<framework>-<version>
Please checkout the complete modified proposal I send to this list yesterday and the further discussion on the general list for complete details if you haven't done so already.
If nobody objects against this proposal I'd like to commit my changes in a few hours from now.
I know I'm rushing things here but I have to complete a new base setup for my own portlet developments. If the PMC would decide against the new project or the above configuration has to be changed than I'm in back luck but I'll have to take that risk.
Note: I will delete the current struts-portlet folder but leave the StrutsContextProviderImpl for the time being in the jetspeed commons subproject to allow current Struts Portlet application to keep running (the dependent struts-portlet jars will still be available from the current maven repo and/or www.bluesunrise.com/maven). I have of course already migrated the the struts-demo portlet (moved under applications) and the security demo which also uses it.
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.
As a side note:
Next week I will start creating a base ServletRenderFilterPortlet which will (optional) allow SiteMesh to decorate the render result of portlets using servlet 2.3 (only from servlet 2.4 servlet filters can be used for included requests). I will then extend StrutsPortlet from the ServletRenderFilterPortlet so SiteMesh can be used to decorate Struts portlets. If it all works out well the ServletRenderFilterPortlet can also go into the framework common package.
I like also to propose a common base package for these bridges: org.apache.jetspeed.portlet.framework.
Then you will get: org.apache.jetspeed.portlet.framework.cocoon org.apache.jetspeed.portlet.framework.common org.apache.jetspeed.portlet.framework.myfaces org.apache.jetspeed.portlet.framework.perl org.apache.jetspeed.portlet.framework.php org.apache.jetspeed.portlet.framework.spring org.apache.jetspeed.portlet.framework.struts org.apache.jetspeed.portlet.framework.velocity ... (getting excited here)
As artifacts of these projects I propose: jetspeed-framework-<framework>-<version>.jar, and jetspeed-framework-<framework>-spi-<version>.jar (if needed)
Then you will get artifacts like jetspeed-framework-struts-2.0-a1-dev.jar and jetspeed-framework-common-2.0-a1-dev.jar
If we can agree on this proposal I'd like to have the struts portlet moved into this new structure early next week, so please be kind to respond asap.
Regards,
Ate
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
