Fwd: New Jakarta proposal: Pluto

[David Sean Taylor <da...@bluesunrise.com>]

Are all of you on the General list? Interesting discussion going on 
there concerning the new Pluto project.
I agree with Costin, that all portlet activity should go through one 
Jakarta project.
When IBM suggested making a new project called Pluto at Jakarta, I was 
happy just to see it going into Jakarta.
Guess I don't feel too strongly against having 3 projects (Jetspeed, 
Pluto, Charon), but it just seems more logical to have them all under 
one main project.
They are all portal projects, and it can be confusing to users.
Perhaps /jetspeed/pluto, jetspeed/charon. What do you all think?

Also see the Wiki:

  http://nagoya.apache.org/wiki/apachewiki.cgi?TalkPlutoProposal
http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal


Begin forwarded message:

> From: Costin Manolache <cm...@yahoo.com>
> Date: Wed Jan 22, 2003  7:51:08  AM US/Pacific
> To: general@jakarta.apache.org
> Subject: Re: New Jakarta proposal: Pluto
> Reply-To: "Jakarta General List" <ge...@jakarta.apache.org>
>
> Stefan Hepper wrote:
>
>> - Pluto is only the reference implementation for the Portlet API 
>> defined
>> in the JSR 168
>> This is comparable with the tomcat being the servlet container and
>> implementing the servlet API.
>> Pluto itself is only a infrastructure component. All portal related
>> functionality like aggreagtion of the output of different portlets,
>> authentication, etc. is NOT part of pluto, but needs to be provided by
>> the portal calling pluto (e.g. JetSpeed or Coocon).
>
> Well - tomcat implements servlet API and JSP, but technically it is 
> not the
> actual reference implementation, it is used in the RI ( J2EE RI AFAIK 
> is
> considered the RI for servlet/JSP ).
> And tomcat implements a bit more than just jsp/servlet - it has admin
> interface, CGI and SSI support, WebDAV and its own extension APIs.
> Same can be said about most other projects that implement APIs ( 
> xerces,
> xalan, axis, etc ).
>
>
>> - Why is Pluto not part of JetSpeed?
>> Pluto has a very restricted scope and is an infrastructure componentet
>> that can be used from serveral other projects (e.g. Cocoon and the
>> proposed Charon). The Portlet API is defined by the JSR and cannot be
>> changed and therefore differs from what you can do in JetSpeed, where
>> you can freely define your API. I could easily see a situation where
>> JetSpeed wants to provide additional functionality beyond the JSR 168
>> 1.0. If these are different sub-projects this is easily possible:
>> JetSpeed could just take Pluto and add functionality.
>
> The API defined in a JSR can't be changed - period. Jetspeed can't take
> pluto and modify some APIs if he wants to - that would be wrong and 
> against
> the JSR rules.
>
> If Pluto community decides to provide additional features, like 
> integration
> in cocoon/struts/etc - I don't see what would stop it and why this 
> would be
> a bad idea.
>
> Maybe my question was wrong - the problem is why Pluto and JetSpeed ( 
> and
> other portlet efforts ) are not in the same community ( with a single
> portlet related mailing list ) ?
>
>
>> - Relation to other Apache projects:
>> JetSpeed and the Coocon portal framework plan to use Pluto (Carstten
>> Ziegler just asked me to include him on the committer list).
>> As Portlets are Web components that may be bundled with other web
>> components, like servlets/JSPs, Pluto will be build ontop of Tomcat.
>> Struts, JSF, and other web frameworks: Portlets sit in front of these
>> frameworks. Each portlet can be viewed as a special web application 
>> that
>> is rendered together with other applications on the same page. The
>> portlet API provides the portal a standard way to call these
>> applications. Each portlet is free to choose how to implement the 
>> logic
>> and rendering inside: using JSPs, Struts, JSF, XML, ...
>
> I would preffer that all portlet-related technology would be in the 
> same
> project and community, with JSP/struts/cocoon specific areas. Maybe an
> "commons"-like project.
>
> Please don't treat my questions as oposition to Pluto proposal - I 
> think
> it's a good thing and I would be happy to see it in Jakarta. I just 
> think
> it would be better for pluto and portlets in general if a bigger 
> community
> would be around it and all rendering frameworks would cooperate ( at 
> least
> in support for portlets ). That could result in a consistent portlet
> support, or at least some sharing of ideas - and get enough review to
> whatever happens there.
>
>
>
> Costin
>
>
>
>
>
>
>
> --
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
>
>
>

--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: New Jakarta proposal: Pluto

[Mark Orciuch <ma...@ngsltd.com>]

> Are all of you on the General list? Interesting discussion going on
> there concerning the new Pluto project.
> I agree with Costin, that all portlet activity should go through one
> Jakarta project.
> When IBM suggested making a new project called Pluto at Jakarta, I was
> happy just to see it going into Jakarta.
> Guess I don't feel too strongly against having 3 projects (Jetspeed,
> Pluto, Charon), but it just seems more logical to have them all under
> one main project.
> They are all portal projects, and it can be confusing to users.
> Perhaps /jetspeed/pluto, jetspeed/charon. What do you all think?
>

You would have my vote on making these subprojects of jetspeed
(/jetspeed/pluto, jetspeed/charon) if only because "jetspeed" is already an
open source portal brand name and has an existing community built around it.

Best regards,

Mark Orciuch - morciuch@apache.org
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>