Andrew C. Oliver wrote:
I paste here an excertp from a mail in Jetspeed-dev, for people wanting to know more. You can track the whole thread in:Sam Ruby wrote:robert burrell donkin wrote:+1 (providing that andrew's reservations about pluto are resolved) why not portlet.apache.org (with jetspeed and pluto as subprojects)?
I predict that something along those lines will eventually occur. The question is whether to gate this donation on such an eventuallity. My recomendation is no, particularly jakarta's track record of being supportive for subprojects becoming sister ASF projects.
+1 -Andy
http://marc.theaimsgroup.com/?t=104315831900002&r=1&w=2
---pasted from Jetspeed-dev---
Luta, Raphael (VUN) wrote:
> De : Weaver, Scott [mailto:[EMAIL PROTECTED]]
>
>>
>>I'm not on general, but I did read the archived stuff on the
>>recent Pluto discussion. I have to admit I am somewhat confused.
>>
>
>
> OK, I'll try to explain what I understood of the situation (however
> I'm not on the JSR so I may be wrong on some specifics).
>
>
>>I had a strong feeling that the RI for JSR 168 was going to
>>be Apaches's baby. However, I would like a clearer view on
>>how Jetspeed fit's into this. I have spent a lot of time
>>building our company's portal offering around Jetspeed and
>>would hate to see it become the red headed step child, as I
>>think all of us would, that gets a thorough beating from
>>"standards" based portals. I am also starting to get
>>questions from management about using Websphere portlets in
>>our offering (Jetpeed), I keep saying "wait until JSR-168."
>>
>
If I understand correctly your concerns, the point is that the
"Jetspeed" brand should not get lost in the process. This is good,
because, even with its limitations, Jetspeed is getting a brand, and we
should not spoil it in the name of something of which we haven't seen
anything yet (private SPEC, no code shown in advance, etc.)
I have read about having a project called portlet.apache.org, which
could have Pluto, Charon, Jetspeed and other initiatives (Cocoon-based,
Struts-based, etc.) hanging below it. It looks like this could be a good
solution from the political POV, while allowing the obvious technical
advantages of having a standard API.
It would also allow that several communities (Cocoon, Struts, Turbine at
the very least) to communicate closely around the portal issues each one
of them is facing separately now.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
