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?
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 :-(
> 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.
And so will I :-)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
