Julie thanks for the response.
I've been delayed on proceeding with committing my latest proposal (which I forgot to cc to this list so here is the link: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=16580).
Scott Weaver also wasn't too keen on using "commons" and suggested "portlet.framework". But "bridges" is I think an even better alternative (sigh: I suppose I'm going to refactor my own changes for the third time).
Because of my own delay I now want to postpone committing my changes one more day.
Lets recap on the different naming proposals and if anyone feels the need please give a vote on these below (I restrict this to the package naming, the rest can be find in the mail history):
[ ] org.apache.portals.bridges. [ ] org.apache.portals.portlet.framework. [ ] org.apache.portals.commons.
Once I've committed my changes (temporarily) in the J2 repository I'd like to know how to proceed for proposing a new Portals subproject (Commons, Bridges, whatever).
I've found the instructions for creating a complete new ASF project but this concerns just a subproject. As I understood from Raphael Luta this is up to the PMC to decide.
Well, first of all, who *is* on the Portals PMC? I couldn't find it anywhere and that would be nice to know anyway.
Secondly, can someone who is member of the PMC enlighten me how to proceed?
Regards,
Ate Douma
Julie MacNaught wrote:
+1 on this concept, but I'd like to discuss the naming a little more.
How about "bridges" instead. The word "commons" and the word "framework" are too generic. I believe "bridges" is more descriptive of the functions we are proposing to include, because we are bridging from some portlet implementation to the JSR168 container.
So instead:
Base package: org.apache.portals.bridges.
Then you will get: org.apache.portals.bridges.common (provides generic features and spi like for struts, php) org.apache.portals.bridges.myfaces org.apache.portals.bridges.perl org.apache.portals.bridges.php org.apache.portals.bridges.spring org.apache.portals.bridges.struts org.apache.portals.bridges.velocity ...
For taglib uri specifications: http://portals.apache.org/bridges/
The struts portlet taglib then will have as uri: http://portals.apache.org/bridges/struts/tags-portlet
Maven groupId: portals-bridges Maven artifactId: portals-bridges-<framework>-<version>
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.
IMO, the usefulness of the Struts Portlet or Perl/PHP Portlet applications way exceeds the scope of Jetspeed and should be promoted
accordingly.
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 :-)
-- 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]
