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.
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." As for Jetspeed becoming the RI, I can already see issues with struts/tiles users not wanting to play with the turbine-driven MVC model that is the current basis for Jetspeed. I don't blame them. Struts is a powerful MVC framework and there should be no need to learn another one just to use the portal RI. I have already seen this issue pop up in jetspeed-user. This leads to the usage of jsp's within turbine, which never was a real priority in the past. However, I do have to admit that Mark Orciuch has really done an excellent job of making Jetspeed play nicely with jsp's which I think has helped retain/gain additional Jetspeed users as it appears more and more of the questions on jetspeed-user have a JSP focus. Finally, what is Charon, besides Pluto's solitary moon ;). Is it a project? Is there an existing code-base? Thanks, Scott > -----Original Message----- > From: David Sean Taylor [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 22, 2003 2:34 PM > To: Jetspeed List > Subject: Fwd: New Jakarta proposal: Pluto > > 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 <[EMAIL PROTECTED]> > > Date: Wed Jan 22, 2003 7:51:08 AM US/Pacific > > To: [EMAIL PROTECTED] > > Subject: Re: New Jakarta proposal: Pluto > > Reply-To: "Jakarta General List" <[EMAIL PROTECTED]> > > > > 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: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > David Sean Taylor > Bluesunrise Software > [EMAIL PROTECTED] > +01 707 773-4646 > > > > > -- > To unsubscribe, e-mail: <mailto:jetspeed-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:jetspeed-dev- > [EMAIL PROTECTED]>
