You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2004/07/25 02:41:44 UTC
[J2] Portlet Frameworks subproject proposal
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: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
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.jar
Note: 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: 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
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Portlet Frameworks subproject proposal
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
I REALLY don't care for the commons moniker, it is so overused. I would
prefer org.apache.portals.portlet.framework.
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: 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 *
* <we...@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
Re: [J2] Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
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: 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
Re: [J2] Portlet Frameworks subproject proposal
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
Great idea! +1
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: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
--
******************************************
* Scott T. Weaver *
* <we...@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
Re: [J2] Portlet Frameworks subproject proposal
Posted by Paul Spencer <pa...@mindspring.com>.
+1 on the framework. I like the idea of separating them from J2. Thus
a failure building a framework will NOT cause a failure in the J2 build.
The frameworks can also be released independently from J2, like Maven
plugins are independent from Maven.
Paul Spencer
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: 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
Re: [J2] Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
Raphaël Luta wrote:
> [Discussion moved to general@portals.apache.org]
>
> 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.
What I propose are not *complete* JSR168 compliant portlets in the meaning that
you would be able to just deploy them...
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
>
> 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.
+1
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.
>
> 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
Re: [J2] Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
Cc'ed to the dev list as I'm not sure all J2 committers subscribed to the
general portals list (as I didn't yet before, shame on me).
Raphaël Luta wrote:
> Ate Douma wrote:
>
> > Repost of a response I already send to the Jetspeed dev list (missed
> the move to this list).
> >
> > Raphaël Luta wrote:
> >
> >> Ate Douma wrote:
> >>
> >>> 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.
> >
> >
> > What I propose are not *complete* JSR168 compliant portlets in the
> meaning that you would be able to just deploy them...
> >
> > 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.
> >
>
> OK. Let's just settle on the following defintiions then: these
> portlets/frmeworks do not require any Jetspeed specific API to work as
> expected. Agreed ?
Yes.
>
> >
> >>
> >> 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.
> >
> >
> > +1
> > 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.
> >
>
> I don't think it should matter. you don't decide to stay within a
> project just to avoid setting up the infrastructure required for a
> new sub-project.
> The main consequence of not staying within Jetspeed is that creating
> such a sub-project requires Portals PMC awareness and approval which
> is a good thing in my book.
> I think we can easily wait 1 or 2 weeks for the infrastructure guys
> to setup the repositories and mailing-lists and even possibly
> give them a hand there.
> It's much better to think of long term community benefits than short
> term delay avoidance.
I fully agree, don't get me wrong.
But, I am technically responsible for several portlet projects which are going
to use my struts portlet framework starting next week. For this I have to write
instructions, specifications, guidelines and the infrastructure.
I cannot afford rewriting these as well as have them change all the package and
resource references (one in each JSP for the taglib!).
If the PMC at least could agree on the project, package and resource (taglib
uri) naming proposal then I can anticipate on this. By temporarily storing the
frameworks under J2 (in my proposed folder portals-commons) the creation and
configuration of the new project can be done without rush.
If I have your (and other committers) support for this proposal, and none is
against it, I am willing to take the chance the PMC might decide against it or
not as I anticipated (e.g. an other naming choosen).
Would this be acceptable?
>
> > 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:
> >
>
> +1 (but subject to PMC approval which I'm currently not part of)
>
> > <snip portal-commons naming proposal>
>
> >
> > 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.
> >
>
> Are you really in such a hurry to commit those changes ? I'm personnally
> -0 on such moves before a consensus is achieved but I understand that
> you may specific business developments depending on those packages.
See above. I don't like it myself to rush things like this but the projects I'm
responsible for are rushed themselves and so I must follow :-(
>
> >>
> >> 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 :-)
> >
>
> I certainly hope J2 to make an impression but at the same time I'd
> definitely like to work towards improving the overall value of the
> Portals project. I'll be extremely happy if we manage to create
> enough diversity and communities within Portals so that it can
> become *the* reference site for quality portal related code.
And so will I :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
Cc'ed to the dev list as I'm not sure all J2 committers subscribed to the
general portals list (as I didn't yet before, shame on me).
Raphaël Luta wrote:
> Ate Douma wrote:
>
> > Repost of a response I already send to the Jetspeed dev list (missed
> the move to this list).
> >
> > Raphaël Luta wrote:
> >
> >> Ate Douma wrote:
> >>
> >>> 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.
> >
> >
> > What I propose are not *complete* JSR168 compliant portlets in the
> meaning that you would be able to just deploy them...
> >
> > 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.
> >
>
> OK. Let's just settle on the following defintiions then: these
> portlets/frmeworks do not require any Jetspeed specific API to work as
> expected. Agreed ?
Yes.
>
> >
> >>
> >> 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.
> >
> >
> > +1
> > 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.
> >
>
> I don't think it should matter. you don't decide to stay within a
> project just to avoid setting up the infrastructure required for a
> new sub-project.
> The main consequence of not staying within Jetspeed is that creating
> such a sub-project requires Portals PMC awareness and approval which
> is a good thing in my book.
> I think we can easily wait 1 or 2 weeks for the infrastructure guys
> to setup the repositories and mailing-lists and even possibly
> give them a hand there.
> It's much better to think of long term community benefits than short
> term delay avoidance.
I fully agree, don't get me wrong.
But, I am technically responsible for several portlet projects which are going
to use my struts portlet framework starting next week. For this I have to write
instructions, specifications, guidelines and the infrastructure.
I cannot afford rewriting these as well as have them change all the package and
resource references (one in each JSP for the taglib!).
If the PMC at least could agree on the project, package and resource (taglib
uri) naming proposal then I can anticipate on this. By temporarily storing the
frameworks under J2 (in my proposed folder portals-commons) the creation and
configuration of the new project can be done without rush.
If I have your (and other committers) support for this proposal, and none is
against it, I am willing to take the chance the PMC might decide against it or
not as I anticipated (e.g. an other naming choosen).
Would this be acceptable?
>
> > 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:
> >
>
> +1 (but subject to PMC approval which I'm currently not part of)
>
> > <snip portal-commons naming proposal>
>
> >
> > 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.
> >
>
> Are you really in such a hurry to commit those changes ? I'm personnally
> -0 on such moves before a consensus is achieved but I understand that
> you may specific business developments depending on those packages.
See above. I don't like it myself to rush things like this but the projects I'm
responsible for are rushed themselves and so I must follow :-(
>
> >>
> >> 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 :-)
> >
>
> I certainly hope J2 to make an impression but at the same time I'd
> definitely like to work towards improving the overall value of the
> Portals project. I'll be extremely happy if we manage to create
> enough diversity and communities within Portals so that it can
> become *the* reference site for quality portal related code.
And so will I :-)
Re: [J2] Portlet Frameworks subproject proposal
Posted by Raphaël Luta <ra...@apache.org>.
Ate Douma wrote:
> Repost of a response I already send to the Jetspeed dev list (missed
the move to this list).
>
> Raphaël Luta wrote:
>
>> Ate Douma wrote:
>>
>>> 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.
>
>
> What I propose are not *complete* JSR168 compliant portlets in the
meaning that you would be able to just deploy them...
>
> 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.
>
OK. Let's just settle on the following defintiions then: these
portlets/frmeworks do not require any Jetspeed specific API to work as
expected. Agreed ?
>
>>
>> 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.
>
>
> +1
> 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.
>
I don't think it should matter. you don't decide to stay within a
project just to avoid setting up the infrastructure required for a
new sub-project.
The main consequence of not staying within Jetspeed is that creating
such a sub-project requires Portals PMC awareness and approval which
is a good thing in my book.
I think we can easily wait 1 or 2 weeks for the infrastructure guys
to setup the repositories and mailing-lists and even possibly
give them a hand there.
It's much better to think of long term community benefits than short
term delay avoidance.
> 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:
>
+1 (but subject to PMC approval which I'm currently not part of)
> <snip portal-commons naming proposal>
>
> 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.
>
Are you really in such a hurry to commit those changes ? I'm personnally
-0 on such moves before a consensus is achieved but I understand that
you may specific business developments depending on those packages.
>>
>> 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 :-)
>
I certainly hope J2 to make an impression but at the same time I'd
definitely like to work towards improving the overall value of the
Portals project. I'll be extremely happy if we manage to create
enough diversity and communities within Portals so that it can
become *the* reference site for quality portal related code.
--
Raphael Luta - raphael@apache.org
Apache Jetspeed - Enterprise Portal in Java
http://portals.apache.org/
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by Raphael Luta <ra...@apache.org>.
[Dropped the cc: to Jetspeed-dev, by now everyone interested should be
on general@portals :) ]
Ate Douma wrote:
>
> 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.
>
I agree that bridges is the better of the 3 propositions.
> 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?
>
That I know for sure:
- Santiago Gala (PMC Chair)
- David Taylor
- Carsten Ziegler
Beyond that, I guess most of the usual suspects are part of the PMC
(Scott, Paul, Jeremy, etc...). Note that if you wish to join the PMC you
need simply to ask and the current PMC members will consider the request.
To officialy request a decision on creating a sub-project, a mail like
this one on general@portals is in theory enough, although you may
want to cc pmc@portals.apache.org to make sure the PMC members are
paying attention.
--
Raphaël Luta - raphael@apache.org
Apache Jetspeed - Enterprise Portal in Java
http://portals.apache.org/
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
>
> On Jul 29, 2004, at 5:50 AM, Scott T. Weaver wrote:
>
>> 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.
>
>
>
> Sorry I've been on vacation, coming in a little late here (hopefully not
> too late)
> I've been writing about this concept a lot recently
That might be interesting. Something you are willing/allowed to share?
, and in my mind, it
> always seems like 'frameworks', although bridges sounds good too, it has
> a slight negative connotation as in 'bridging' from one thing to
> another, as opposed to frameworks being a foundation for building apps upon
>
> [x] org.apache.portals.frameworks
Never too late :-) although I've already started refactoring (again) going for
bridges now.
I understand your argument and agree to some degree with it. It depends on the
"framework" on which to build though I think.
Some of the mentioned "frameworks" (struts, jsf, spring) are proper frameworks
in their own respect. One using a "bridge" to these frameworks is more likely
using mainly those frameworks features, the "bridge" should probably be less
considered as such.
Which doesn't mean I wouldn't like to see "full" portlet frameworks hosted under
Portals though :-) under "Commons" or even another subproject.
Considering the votes now given (bridges: 6, frameworks: 1) I will go for the
bridges proposal from Julie.
With regards,
>
>
>
>>>
>>> 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
>
>
> I also know of one person working on a framework (bridge) for Groovy
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194
>
>
>
>
>
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Jul 29, 2004, at 5:50 AM, Scott T. Weaver wrote:
> 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.
Sorry I've been on vacation, coming in a little late here (hopefully
not too late)
I've been writing about this concept a lot recently, and in my mind, it
always seems like 'frameworks', although bridges sounds good too, it
has a slight negative connotation as in 'bridging' from one thing to
another, as opposed to frameworks being a foundation for building apps
upon
[x] org.apache.portals.frameworks
>>
>> 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
I also know of one person working on a framework (bridge) for Groovy
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
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 *
* <we...@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
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by Gaurav Vaish <ga...@gmail.com>.
Ditto
+1 for bridges.
Gaurav
On Wed, 28 Jul 2004 18:10:49 -0400, Julie MacNaught <jm...@apache.org> wrote:
> [ X] org.apache.portals.bridges.
> +1
>
> I volunteer to organize the PMC vote to add the subproject if we can get
> consensus here. If the PMC approves, then we ask infrastructure to
> create the CVS tree, emails lists, and whatnot. We also have to decide
> who the initial committers are.
>
> The Portals PMC has the following members, AFAIK:
>
> * Jeremy Ford <jf...@apache.org>
> * Santiago Gala <sg...@apache.org>
> * Stefan Hepper <st...@apache.org>
> * Julie MacNaught <jm...@apache.org>
> * Davanum Srinivas <di...@apache.org>
> * David Sean Taylor <ta...@apache.org>
> * Scott Weaver <we...@apache.org>
> * Carsten Ziegeler <cz...@apache.org>
>
>
>
>
> 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):
> >
> > [ ] 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
>
> --
> Julie MacNaught
> IBM Research
> jmacna@apache.org
> jmacna@us.ibm.com
>
>
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by Julie MacNaught <jm...@apache.org>.
[ X] org.apache.portals.bridges.
+1
I volunteer to organize the PMC vote to add the subproject if we can get
consensus here. If the PMC approves, then we ask infrastructure to
create the CVS tree, emails lists, and whatnot. We also have to decide
who the initial committers are.
The Portals PMC has the following members, AFAIK:
* Jeremy Ford <jf...@apache.org>
* Santiago Gala <sg...@apache.org>
* Stefan Hepper <st...@apache.org>
* Julie MacNaught <jm...@apache.org>
* Davanum Srinivas <di...@apache.org>
* David Sean Taylor <ta...@apache.org>
* Scott Weaver <we...@apache.org>
* Carsten Ziegeler <cz...@apache.org>
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):
>
> [ ] 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
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
--
Julie MacNaught
IBM Research
jmacna@apache.org
jmacna@us.ibm.com
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
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
>
>
>
>
Re: [J2] VOTE: Portlet Frameworks subproject proposal
Posted by Paul Spencer <pa...@apache.org>.
Ate Douma wrote:
> 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.
+1
Paul Spencer
[J2] VOTE: Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
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 - 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
>>>
>>>
>>>
>>>
>>
>>
>
[J2] VOTE: Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
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 - 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
Re: [J2] Portlet Frameworks subproject proposal
Posted by Julie MacNaught <jm...@apache.org>.
+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
>>
>>
>>
>>
>
>
--
Julie MacNaught
IBM Research
jmacna@apache.org
jmacna@us.ibm.com
Re: [J2] Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
Repost of a response I already send to the Jetspeed dev list (missed the move to
this list).
Raphaël Luta wrote:
> [Discussion moved to general@portals.apache.org]
>
> 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.
What I propose are not *complete* JSR168 compliant portlets in the meaning that
you would be able to just deploy them...
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
>
> 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.
+1
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.
>
> 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
>
>
>
>
Re: [J2] Portlet Frameworks subproject proposal
Posted by Raphaël Luta <ra...@apache.org>.
[Discussion moved to general@portals.apache.org]
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.
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.
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.
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 - 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
Re: [J2] Portlet Frameworks subproject proposal
Posted by Raphaël Luta <ra...@apache.org>.
[Discussion moved to general@portals.apache.org]
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.
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.
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.
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 - raphael@apache.org
Apache Jetspeed - Enterprise Portal in Java
http://portals.apache.org/
Re: [J2] Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
Roger Ruttimann wrote:
> +1 on the Framework.
I've already started refactoring :-)
So far I've got the struts portlet framework done and the struts-demo moved
under applications (so I could remove the struts-portlet root folder).
For the original StrutsServletContextProvider interface (which is the same as
your PHPServletContextProvider) I created a new ServletContextProvider interface
in the new common portlet framework and a corresponding
ServletContextProviderImpl in commons.
Note: I left the StrutsContextProviderImpl for the time being (but with a
@deprecated tag) because I don't know if the Struts Portlet is used in Fusion
for instance. Once all are migrated to the new interface I want to drop both the
Struts specific interface and implementation.
If you want I can do the work for the PHP framework like I did for the Struts
Portlet framework, replace the usage of the PHPServletContextProvider with
ServletContextProvider and PHPServletContextProviderImpl with
ServletContextProviderImpl.
Note the changed proposal for using a new Portals Commons subproject based on
the suggestion of Raphaël Luta.
I don't know yet what the outcome of that will be but if positive I will do it
according to the latest proposal.
> I submitted the Perl and PHP framework as portlet applications (no
> dependencies on J2) which could easily ported over to the the proposed
> framework.
This is correct for the PHP framework but the Perl framework is still dependent
on J2 JetspeedPortletContext... As such it cannot be moved yet.
>
> Roger
>
> 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: 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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] Portlet Frameworks subproject proposal
Posted by Roger Ruttimann <ro...@apache.org>.
+1 on the Framework.
I submitted the Perl and PHP framework as portlet applications (no
dependencies on J2) which could easily ported over to the the proposed
framework.
Roger
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: 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
Re: [J2] Portlet Frameworks subproject proposal
Posted by Ate Douma <at...@douma.nu>.
Small corrections to my proposal below
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)
Better specified I think as:
jetspeed-framework-<project Id>-<version>.jar, and
jetspeed-framework-<project Id>-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
Actually, the version should *not* be in sync (per se) with the J2 version as
these projects are intentionally independent of J2. Thus the first versions of
these above more likely are:
jetspeed-framework-struts-0.2.jar and
jetspeed-framework-common-0.1.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: 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