You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@portals.apache.org by Raphaël Luta <ra...@apache.org> on 2004/07/26 13:20:47 UTC
Re: [J2] Portlet Frameworks subproject proposal
[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>.
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
>
>
>
>