portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T. Weaver" <scotts-jetspeed-l...@binary-designs.net>
Subject Re: [J2] VOTE: Portlet Frameworks subproject proposal
Date Thu, 29 Jul 2004 12:50:10 GMT
Ate Douma wrote:

> 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):
>
>   [x] 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 - raphael@apache.org
>>>> Apache Jetspeed - Enterprise Portal in Java
>>>> http://portals.apache.org/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


-- 
******************************************
*           Scott T. Weaver              *
*         <weaver@apache.org>            *
*     <http://www.einnovation.com>       *
* -------------------------------------- *
*   Apache Jetspeed Enterprise Portal    *
*     Apache Pluto Portlet Container     *
*                                        *
* OpenEditPro, Website Content Mangement *
*     <http://www.openeditpro.com>       *
******************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message