Re: New Jakarta proposal: Pluto
I think the incubator should take in to account that committers/memebers w/in the Jakarta Community have serious reservations about the community issues here. While I really want to see this happen here, Steven is right to question some serious community issues. BTW here are mine: Please note that my support is based on the following assumptions: 1. all spec/seed code will be released (this, in my opinion, must be done prior to consideration) If thats not till March, then the project can't reasonably be considered until March. (We don't take on other closed source projects) 2. David Taylor and the other committee members will soon be released from the Non-Disclosure agreements they are currently under so that they can participate freely. (You can't have a community based on a closed spec where the members can't speak freely). 3. I'm assuming that others including from the Jetspeed and Cocoon-portal will go add themselves as committers... http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal - I will send an invitation out. 4. The project will keep compatibilty with the spec but we'll be free to expand beyond it in much the same way Tomcat and other projects do. Xerces, for instance, doesn't solely implement just SAX and JAXP with a parser under it. From a performance standpoint, SAX interfaces would be nice, having them in the RI (extending the spec) would serve this purpose. 5. Future revisions of the Spec will happen in the open. Please note, I REALLY want to see this at Apache, so this is not a fillibuster intended to kill the effort to be followed by a series of Catch-22 arguments (here, but not there, which means it can't be here). But I don't feel the participants should be given a free pass into Apache to create non community-based non-open projects just to get the feather. If this is going to be an Apache project, it does need to be an Apache project. If there is motivation on everyone's part, we CAN obviously fix these issues by addressing them head-on in an honest and straightforward manner. I DO want to particpate, and I DO want to see this happen, but lets do the community thing. We can certainly resolve these issues if all parties are motivated. -AndrewCOliver I've also posted them here: http://nagoya.apache.org/wiki/apachewiki.cgi?TalkPlutoProposal -Andy Steven, I think these are exactly the sort of questions incubator is designed to answer. Tapestry was about seeing how an existing project can come into Apache. Perhaps Pluto is an opportunity to understand how a new project can be created and encouraged at Apache. They are both interesting challenges for the incubator. As for your issues, No code is true (for now) but that is the sort of project Pluto represents. If at the end, the incubator PMC decides that the project still has the problems you identify (if they are in fact problems), then the project should remain in incubation until the community is self supporting, or be discontinued, whatever. That is a decision for further down the track, I think.It would seem to me that if JetSpeed is in scope for Jakarta, IMHO, a reference implementation at Apache of a Portal standard would be appropriate, especially considering JetSpeed is already at Jakarta. I'm not into portals myself so I can't really comment on the project's merits beyond that. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Conor MacNeill wrote: Steven, I think these are exactly the sort of questions incubator is designed to answer. Tapestry was about seeing how an existing project can come into Apache. Perhaps Pluto is an opportunity to understand how a new project can be created and encouraged at Apache. They are both interesting challenges for the incubator. I volunteered for being on the Pluto project team, if only for discussion and documentation. That way, I hope to be able to take care about my reservations, by making sure I'm right in the middle of it. It's good to see Carsten and Andy, too. That makes 3 of us who will make sure Pluto integrates with Cocoon. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Andrew C. Oliver wrote: Please note that my support is based on the following assumptions: http://nagoya.apache.org/wiki/apachewiki.cgi?TalkPlutoProposal Andy, This is an *excellent* list to work from. Thanks! - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
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]
Re: New Jakarta proposal: Pluto
Steven Noels wrote: Conor MacNeill wrote: Steven, I think these are exactly the sort of questions incubator is designed to answer. Tapestry was about seeing how an existing project can come into Apache. Perhaps Pluto is an opportunity to understand how a new project can be created and encouraged at Apache. They are both interesting challenges for the incubator. I volunteered for being on the Pluto project team, if only for discussion and documentation. That way, I hope to be able to take care about my reservations, by making sure I'm right in the middle of it. It's good to see Carsten and Andy, too. That makes 3 of us who will make sure Pluto integrates with Cocoon. /Steven I will try to join both Pluto and Charon, also, time and health permitting. Even if I am not very active lately, I'm still tracking Cocoon and Jetspeed as much as I can. I'm better at bug fixing, critisizing and generic hacking than a true programmer, but I think debuggers are always needed. I would like to see what comes out of this, after a couple of years involved into this stuff ;-) Regards, Santiago -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
At 08:20 PM 1/22/2003 +0100, you wrote: I will try to join both Pluto and Charon, also, time and health permitting. Even if I am not very active lately, I'm still tracking Cocoon and Jetspeed as much as I can. I'm better at bug fixing, critisizing and generic hacking than a true programmer, but I think debuggers are always needed. I would like to see what comes out of this, after a couple of years involved into this stuff ;-) I'm interested in participating in the Pluto project too, since it meets my company's current interests too. How much involvment I can have and how I will contribute remains to be seen though :) At the least I'll review, at the most I'll help with the code... Regards, Serge Huber. Jahia : A collaborative source CMS and Portal Server www.jahia.org Community and product web site www.jahia.com Commercial services company -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
On Wednesday, January 22, 2003, at 03:51 PM, Costin Manolache wrote: snip 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. +1 (providing that andrew's reservations about pluto are resolved) why not portlet.apache.org (with jetspeed and pluto as subprojects)? (also within jakarta, of course :) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
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 - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
I would like to state my support and desire to be involved in the project. I do kinda think a project proposal might be premature since the specification isn't public yet. -Andy Stefan Hepper wrote: Hi all, I would like to propose a new Jakarta project, named Pluto, that should provide the reference implementation of the JSR 168 Portlet Specification. Please see http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal for more details (I've also attached the proposal below). Regards, Stefan --- Proposal for Pluto - A Jakarta Subproject 21 January 2003, Stefan Hepper ([EMAIL PROTECTED]) (0) rationale To enable interoperability between Portlets and Portals, IBM and SUN initiated the JSR 168. This JSR will define a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security. It will define Portlets, the Portlet container behavior, invocation of Portlets, Portlet services, a Portlet window, event model, and other relevant entities and interfaces. For more information see http://jcp.org/en/jsr/detail?id=168. As part of this JSR a reference implementation of the portlet container, which is the run-time environment of the Portlets, will be created. This reference implementation will be based on the Tomcat subproject. There are two other projects at Jakarta, which could pick up the reference implementation of the portlet container to leverage that work. One is the JetSpeed? portal project and the other one is the Charon proposal. The portlet container will be build on top of the Servlet container and JetSpeed? can use this container in its particular portal implementation, other persons or companies also could pick up the portlet container reference implementation and use it for their products. Having Pluto done under Apache would also ensure that there is a tight communication between the developers of the Servlet container, the portlet container, the portal, and the WSRP implementation proposal Charon. (1) scope of the subproject The only purpose of this subproject is to create and maintain a reference implementation for the Java Portlet specification as defined in http://jcp.org/jsr/detail/168.jsp . The goal for the reference implementation is to create an independent portlet container that may be plugged into every possible driver, for instance JetSpeed?. This project will not create a new portal, but only a reference implementation of a portlet container. There is an agreement with JetSpeed? that the JetSpeed? will be based on this portlet container implementation. (2) identify the initial source from which the subproject is to be populated The JSR 168 Expert Group has a prototype based on Tomcat, which will be the starting point for the subproject. This prototype will be submitted to Jakarta after the first JSR 168 draft is made public available, which is currently scheduled for end of March. (3) identify the Jakarta resources to be created (3.1) mailing list(s) pluto-user pluto-dev (3.2) CVS repositories jakarta-pluto (3.3) Bugzilla (3.4) Jyve FAQ (when available) pluto-general (4) identify the initial set of committers Stefan Hepper ([EMAIL PROTECTED]) Stephan Hesmer ([EMAIL PROTECTED]) Birga Rick ([EMAIL PROTECTED]) David Sean Taylor ([EMAIL PROTECTED]) Alejandro Abdelnur ([EMAIL PROTECTED]) (5) identify apache sponsoring individual Sam Ruby ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Stefan Hepper wrote: Hi all, I would like to propose a new Jakarta project, named Pluto, that should provide the reference implementation of the JSR 168 Portlet Specification. Please see http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal for more details (I've also attached the proposal below). Regards, Stefan Stefan, Are you aware of the apache incubator? I assume this would have to go through the incubator first. Are we still using Jyve for FAQs (or am I thinking of the wrong Jyve)? Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Andrew C. Oliver wrote: I would like to state my support and desire to be involved in the project. I do kinda think a project proposal might be premature since the specification isn't public yet. I was trying not to post the obvious, but yes: this seems largely premature. No code, a restricted community, too much committers coming from one company, I've seen better proposals being fought over lately. Also, possible future integration 'ideas' with some related projects would be comforting (Jetspeed, Tomcat, Struts/Tiles, and the Cocoon portal framework for a starter). /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Note the mail was cc'd to both. Conor MacNeill wrote: Stefan Hepper wrote: Hi all, I would like to propose a new Jakarta project, named Pluto, that should provide the reference implementation of the JSR 168 Portlet Specification. Please see http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal for more details (I've also attached the proposal below). Regards, Stefan Stefan, Are you aware of the apache incubator? I assume this would have to go through the incubator first. Are we still using Jyve for FAQs (or am I thinking of the wrong Jyve)? Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
On Tue, 21 Jan 2003, Steven Noels wrote: Andrew C. Oliver wrote: project. I do kinda think a project proposal might be premature since the specification isn't public yet. I was trying not to post the obvious, but yes: this seems largely premature. No code, a restricted community, too much committers coming from one company, I've seen better proposals being fought over lately. Also, possible future integration 'ideas' with some related projects would be comforting (Jetspeed, Tomcat, Struts/Tiles, and the Cocoon portal framework for a starter). Is this different from Tomcat and/or JSTL? If so, how? I'm clueless on portlets, but from my 'vague consumer' view, I thought the JSR was standardising a lot of what Jetspeed does. Are there any Jetspeed people on this JSR? Or is it a competing viewpoint? [much like the Log JSR suddenly wanting to turn Log4j into their reference]. Would Jetspeed use Charon/Pluto, or would the fact that it's an RI limit Jetspeed? I'm assuming Tomcat and JSTL had a number of Apache people in the JSR, if this one doesn't, then it seems that it's a sourceforge concept. We'd like an open source RI, let's host at Jakarta, they do open-source RI's. Is this not-invented-here-ism or maintaining scope? Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Henri Yandell wrote: Is this not-invented-here-ism or maintaining scope? From my part: scope fairness. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
At 13:38 21/01/03, Stefan Hepper wrote: Hi all, I would like to propose a new Jakarta project, named Pluto, that should provide the reference implementation of the JSR 168 Portlet Specification. Please see http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal for more details (I've also attached the proposal below). My instant reaction was but we already have Jetspeed and then I read There is an agreement with JetSpeed? that the JetSpeed? will be based on this portlet container implementation. Cool. I think I could persuade more people to use Jetspeed if it used a recognised portlet standard. I then read. (3.4) Jyve FAQ (when available) I don't honestly believe that anyone has any interest in fixing Jyve I said I would some time ago, but failed - I don't even know the password for my [EMAIL PROTECTED] login account any more. I know that we are a eat-our-own-dogfood sort of society but I think this is one situation where we ought to admit that Jyve has failed. If I am wrong and there is a community of people willing to make Jyve work again then great. I would be quite happy being wrong about it. As an example I used to maintain a FOP faq with Jyve. Nowadays however I just use a perl script which displays all the submitted entries. Crude, but it works. http://www.OWAL.co.uk/cgi-bin/fopfaq.cgi Alex McLintock Available for java/perl/C++/web development in London, UK or nearby. Apache FOP, Cocoon, Turbine, Struts,XSL:FO, XML, Tomcat, First meeting free.http://www.OWAL.co.uk/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Steven Noels wrote: I was trying not to post the obvious, but yes: this seems largely premature. Deja vu. Check back next week for the inevitable complaint that Pluto is too mature. No code, a restricted community, too much committers coming from one company, I've seen better proposals being fought over lately. Code is forthcoming. Multiple existing Apache committers. Multiple distinct corporate contributors. In support of a standard (I'll leave that term undefined). Strongly related to an existing Jakarta subproject. I have talked to the person who submitted this proposal, both via notes and on the phone. I gave explicit guidance as to what questions to have answered in the original proposal, where to send it (general AND incubator, if you notice). To post the text on the web AND include it verbatim in the note. Etc. I also gave warning that there is likely to be extended and lengthy discussion as to where this code should land instead of on the merits of the project itself... Also, possible future integration 'ideas' with some related projects would be comforting (Jetspeed, Tomcat, Struts/Tiles, and the Cocoon portal framework for a starter). I can't resist a Jon'ism here: Thanks for volunteering! - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
I've been away from the Jetspeed list, but I believe that they are intending to fully support JSR168. http://jakarta.apache.org/jetspeed/ -- Paul Balogh Co-Owner / Lead Developer The Netrix Group www.netrixgroup.com We live for this stuff... Andrew C. Oliver said: I would like to state my support and desire to be involved in the project. I do kinda think a project proposal might be premature since the specification isn't public yet. -Andy Stefan Hepper wrote: Hi all, I would like to propose a new Jakarta project, named Pluto, that should provide the reference implementation of the JSR 168 Portlet Specification. Please see http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal for more details (I've also attached the proposal below). Regards, Stefan --- Proposal for Pluto - A Jakarta Subproject 21 January 2003, Stefan Hepper ([EMAIL PROTECTED]) (0) rationale To enable interoperability between Portlets and Portals, IBM and SUN initiated the JSR 168. This JSR will define a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security. It will define Portlets, the Portlet container behavior, invocation of Portlets, Portlet services, a Portlet window, event model, and other relevant entities and interfaces. For more information see http://jcp.org/en/jsr/detail?id=168. As part of this JSR a reference implementation of the portlet container, which is the run-time environment of the Portlets, will be created. This reference implementation will be based on the Tomcat subproject. There are two other projects at Jakarta, which could pick up the reference implementation of the portlet container to leverage that work. One is the JetSpeed? portal project and the other one is the Charon proposal. The portlet container will be build on top of the Servlet container and JetSpeed? can use this container in its particular portal implementation, other persons or companies also could pick up the portlet container reference implementation and use it for their products. Having Pluto done under Apache would also ensure that there is a tight communication between the developers of the Servlet container, the portlet container, the portal, and the WSRP implementation proposal Charon. (1) scope of the subproject The only purpose of this subproject is to create and maintain a reference implementation for the Java Portlet specification as defined in http://jcp.org/jsr/detail/168.jsp . The goal for the reference implementation is to create an independent portlet container that may be plugged into every possible driver, for instance JetSpeed?. This project will not create a new portal, but only a reference implementation of a portlet container. There is an agreement with JetSpeed? that the JetSpeed? will be based on this portlet container implementation. (2) identify the initial source from which the subproject is to be populated The JSR 168 Expert Group has a prototype based on Tomcat, which will be the starting point for the subproject. This prototype will be submitted to Jakarta after the first JSR 168 draft is made public available, which is currently scheduled for end of March. (3) identify the Jakarta resources to be created (3.1) mailing list(s) pluto-user pluto-dev (3.2) CVS repositories jakarta-pluto (3.3) Bugzilla (3.4) Jyve FAQ (when available) pluto-general (4) identify the initial set of committers Stefan Hepper ([EMAIL PROTECTED]) Stephan Hesmer ([EMAIL PROTECTED]) Birga Rick ([EMAIL PROTECTED]) David Sean Taylor ([EMAIL PROTECTED]) Alejandro Abdelnur ([EMAIL PROTECTED]) (5) identify apache sponsoring individual Sam Ruby ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
As this is an implementation of a JSR, I believe that the [EMAIL PROTECTED] mailing list should be made aware of those plans... I forwarded your email there... Pier Stefan Hepper [EMAIL PROTECTED] wrote: Hi all, I would like to propose a new Jakarta project, named Pluto, that should provide the reference implementation of the JSR 168 Portlet Specification. Please see http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal for more details (I've also attached the proposal below). Regards, Stefan --- Proposal for Pluto - A Jakarta Subproject 21 January 2003, Stefan Hepper ([EMAIL PROTECTED]) (0) rationale To enable interoperability between Portlets and Portals, IBM and SUN initiated the JSR 168. This JSR will define a set of APIs for Portal computing addressing the areas of aggregation, personalization, presentation and security. It will define Portlets, the Portlet container behavior, invocation of Portlets, Portlet services, a Portlet window, event model, and other relevant entities and interfaces. For more information see http://jcp.org/en/jsr/detail?id=168. As part of this JSR a reference implementation of the portlet container, which is the run-time environment of the Portlets, will be created. This reference implementation will be based on the Tomcat subproject. There are two other projects at Jakarta, which could pick up the reference implementation of the portlet container to leverage that work. One is the JetSpeed? portal project and the other one is the Charon proposal. The portlet container will be build on top of the Servlet container and JetSpeed? can use this container in its particular portal implementation, other persons or companies also could pick up the portlet container reference implementation and use it for their products. Having Pluto done under Apache would also ensure that there is a tight communication between the developers of the Servlet container, the portlet container, the portal, and the WSRP implementation proposal Charon. (1) scope of the subproject The only purpose of this subproject is to create and maintain a reference implementation for the Java Portlet specification as defined in http://jcp.org/jsr/detail/168.jsp . The goal for the reference implementation is to create an independent portlet container that may be plugged into every possible driver, for instance JetSpeed?. This project will not create a new portal, but only a reference implementation of a portlet container. There is an agreement with JetSpeed? that the JetSpeed? will be based on this portlet container implementation. (2) identify the initial source from which the subproject is to be populated The JSR 168 Expert Group has a prototype based on Tomcat, which will be the starting point for the subproject. This prototype will be submitted to Jakarta after the first JSR 168 draft is made public available, which is currently scheduled for end of March. (3) identify the Jakarta resources to be created (3.1) mailing list(s) pluto-user pluto-dev (3.2) CVS repositories jakarta-pluto (3.3) Bugzilla (3.4) Jyve FAQ (when available) pluto-general (4) identify the initial set of committers Stefan Hepper ([EMAIL PROTECTED]) Stephan Hesmer ([EMAIL PROTECTED]) Birga Rick ([EMAIL PROTECTED]) David Sean Taylor ([EMAIL PROTECTED]) Alejandro Abdelnur ([EMAIL PROTECTED]) (5) identify apache sponsoring individual Sam Ruby ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Sam Ruby wrote: Steven Noels wrote: I was trying not to post the obvious, but yes: this seems largely premature. Deja vu. What else could one expect ;-) Check back next week for the inevitable complaint that Pluto is too mature. No code, a restricted community, too much committers coming from one company, I've seen better proposals being fought over lately. Code is forthcoming. Multiple existing Apache committers. Multiple distinct corporate contributors. In support of a standard (I'll leave that term undefined). Strongly related to an existing Jakarta subproject. That remains to be seen and is my major hesitance. Apache doing RIs is kewl in my book. Doing it out of the blue however (sorry for the pun) is another affair. I have talked to the person who submitted this proposal, both via notes and on the phone. I gave explicit guidance as to what questions to have answered in the original proposal, where to send it (general AND incubator, if you notice). To post the text on the web AND include it verbatim in the note. Etc. Sure, it was all by the book. I was lurking on JetSpeed when Thomas became interested in it, BTW. Have lost track since then, and don't know whether any sort of symbiosis between the (hidden) JSR community and Jetspeed community/code exists. These questions should be asked, and I'm not ashamed for standing up. Each in its own turn. I also gave warning that there is likely to be extended and lengthy discussion as to where this code should land instead of on the merits of the project itself... Hey! I'm also doing this by the book then!? :-) I can't resist a Jon'ism here: Thanks for volunteering! I'll interprete that as a Jon'ism. ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Hi, here some answers to questions asked in this thread: - Apache was one of the first memebers in the JSR 168 Expert Group and IBM asked Apache explicitly for their support before submitting this JSR. Currently the Apache resprentative in the Expert Group is David Sean Taylor from the JetSpeed group. - The submitteed JSR states that the RI is planned to do at Apache, so no surprise - There is already code, but as some of you noted at the moment the spec and API is still confidential and therefore nothing is public available. As the proposal states the Expert Group plans to make a spec draft and API draft available around March. As soon as this is done we can check in the code. - Everyone that wants to help is more than welcome to join Regards, Stefan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
At 17:41 21/01/03, you wrote: One more question: why not doing this as a subproject of JetSpeed ? It is an existing jakarta project, the scope matches - why creating a separate jakarta community instead of joining the existing one ? I assume that it would be a tool which could be used by the Cocoon portal system, and a Struts portal system as well as Jetspeed which is essentially a Turbine portal system. People may want to use this component without using Jetspeed. Of course I haven't read the JSR yet. Alex Mc -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Alex McLintock wrote: At 17:41 21/01/03, you wrote: One more question: why not doing this as a subproject of JetSpeed ? It is an existing jakarta project, the scope matches - why creating a separate jakarta community instead of joining the existing one ? I assume that it would be a tool which could be used by the Cocoon portal system, and a Struts portal system as well as Jetspeed which is essentially a Turbine portal system. People may want to use this component without using Jetspeed. Of course I haven't read the JSR yet. A portlet is an object, similar to a servlet, but which generates only a page fragment. A portlet container would be in charge of providing them with a suitable Request, and combining the portlet response to compose the page that the browser will get. (And many more things...) Thus, it is not that simple. You will need a portlet container (which is what essentially is Jetspeed, a portlet container on top of Turbine). During the discussions about the Portlet API proposal in the Jetspeed list, a couple of years ago, I positioned myself (I was not the only one), in a field that considered that we should have two kind of portlets: - Stream based portlets (the original IBM proposal) which would use the response stream to write their content (a la JSP) - SAX portlets, which would use a SAX pipeline to render the content. I remember Raphael Luta was very concerned that any portlet should be a full XML document, because he also was very interested in XML transformations. See a pointer to part of the discussions, for those wanting some info. http://www.mail-archive.com/jetspeed@list.working-dogs.com/msg05070.html http://www.mail-archive.com/jetspeed@list.working-dogs.com/msg05026.html (joke on the saxlet word, that I still claim to have invented, not the concept, though :-( I was rejected as a member of the JSP team, thus I don't know what they are doing in there. On a side note, by exactly the same reason I can speak freely about it. The discussion But I'm quite sure that the only scalable way to have portlets that can be used from Cocoon (or any other XML based framework) will be those using SAX streams or plain XML (let's say DOM) to reder their content. The reason is that portlets that generate a bytestream will need to be re-parsed by any XML-based portlet container, to transform them or serialize again at the end of the page rendering. So, even if portlets are designed to be reusable from different frameworks (Struts, Turbine, Cocoon, etc.), Cocoon would have a nightmare re-parsing and re-serializing portlets if the SAXPortlet is not in the API. Both Turbine and Struts could, of course, use VelocityPortlets, JSPPortlets, and the like. I'm currently interested in javax.portlet.sax.SAXPortlet ;-) (call them saxlets if you like it). Regards, Santiago Alex Mc -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Alex McLintock wrote: At 17:41 21/01/03, you wrote: One more question: why not doing this as a subproject of JetSpeed ? It is an existing jakarta project, the scope matches - why creating a separate jakarta community instead of joining the existing one ? I assume that it would be a tool which could be used by the Cocoon portal system, and a Struts portal system as well as Jetspeed which is essentially a Turbine portal system. People may want to use this component without using Jetspeed. Of course I haven't read the JSR yet. My understanding was that Jetspeed goal is to implement a portal - with Java and XML. I would rather see all portal systems sharing a single community and implementing similar behavior/standards - rather than have one portal for each technology ( struts, cocoon, turbine, tapestry, plain JSP, plain servlet, whatever else toolset ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Sam Ruby wrote: Steven Noels wrote: I was trying not to post the obvious, but yes: this seems largely premature. Deja vu. Check back next week for the inevitable complaint that Pluto is too mature. No code, a restricted community, too much committers coming from one company, I've seen better proposals being fought over lately. Code is forthcoming. I would like to see either the code, or the specification, or both, before being asked to vote for a project, or even to have to decide Jetspeed related issues WRT those new proposals. Multiple existing Apache committers. Multiple distinct corporate contributors. In support of a standard (I'll leave that term undefined). Strongly related to an existing Jakarta subproject. What concerns me is largely the absence of any public discussion around the API proposal. Mostly because of the XML support level. From the origins of the stuff, I remember that the JCP proponents were not suppporting XML stuff at all. Things could have changed a lot, since the world has changed a whole lot in the last two years ;-) I have talked to the person who submitted this proposal, both via notes and on the phone. I gave explicit guidance as to what questions to have answered in the original proposal, where to send it (general AND incubator, if you notice). To post the text on the web AND include it verbatim in the note. Etc. I also gave warning that there is likely to be extended and lengthy discussion as to where this code should land instead of on the merits of the project itself... Also, possible future integration 'ideas' with some related projects would be comforting (Jetspeed, Tomcat, Struts/Tiles, and the Cocoon portal framework for a starter). I can't resist a Jon'ism here: Thanks for volunteering! - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Stefan Hepper wrote: Hi, here some answers to questions asked in this thread: - Apache was one of the first memebers in the JSR 168 Expert Group and IBM asked Apache explicitly for their support before submitting this JSR. Currently the Apache resprentative in the Expert Group is David Sean Taylor from the JetSpeed group. - The submitteed JSR states that the RI is planned to do at Apache, so no surprise - There is already code, but as some of you noted at the moment the spec and API is still confidential and therefore nothing is public available. As the proposal states the Expert Group plans to make a spec draft and API draft available around March. As soon as this is done we can check in the code. Do you mean the PortletAPI branch in the Jetspeed code base? Or is there other code around? - Everyone that wants to help is more than welcome to join Regards, Stefan Regards, Santiago -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
On Tue, 21 Jan 2003, Costin Manolache wrote: Date: Tue, 21 Jan 2003 11:31:32 -0800 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: New Jakarta proposal: Pluto Alex McLintock wrote: At 17:41 21/01/03, you wrote: One more question: why not doing this as a subproject of JetSpeed ? It is an existing jakarta project, the scope matches - why creating a separate jakarta community instead of joining the existing one ? I assume that it would be a tool which could be used by the Cocoon portal system, and a Struts portal system as well as Jetspeed which is essentially a Turbine portal system. People may want to use this component without using Jetspeed. Of course I haven't read the JSR yet. My understanding was that Jetspeed goal is to implement a portal - with Java and XML. I would rather see all portal systems sharing a single community and implementing similar behavior/standards - rather than have one portal for each technology ( struts, cocoon, turbine, tapestry, plain JSP, plain servlet, whatever else toolset ). One thing to remember is that JSR-168 is only standardizing the interface between a portal server and the portlets it calls (just as the servlet spec only defines the interface between a servlet container and the servlets). The architecture of the portal server itself (or the servlet container itself) is not being mandated. Therefore, it's entirely reasonable to have a single portal server implementation (created with whatever server-side technologies the developers of the portal server choose). But it's also reasonable to have different portal servers with different feature sets, aimed at different markets, if that is what folks want to do. But, as Costin says, that should *not* be driven by the technology used to implement the portal server itself. Where the frameworks need to get on board, IMHO, is making it easy to create standard *portlets* using that framework's technology -- that way, someone who wants to deploy a portal is not constrained to only using web components implemented on a single particular framework. And portlet-based Struts applications (for example) could be plugged into anybody's portal server as long as it supports the standard portlet API. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Craig R. McClanahan wrote: snip/ Totally! Anyone doing portal work will probably understand the need for this. -Andy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
From: Henri Yandell bayard at generationjava.com On Tue, 21 Jan 2003, Steven Noels wrote: Andrew C. Oliver wrote: project. I do kinda think a project proposal might be premature since the specification isn't public yet. I was trying not to post the obvious, but yes: this seems largely premature. No code, a restricted community, too much committers coming from one company, I've seen better proposals being fought over lately. Also, possible future integration 'ideas' with some related projects would be comforting (Jetspeed, Tomcat, Struts/Tiles, and the Cocoon portal framework for a starter). Is this different from Tomcat and/or JSTL? If so, how? I'm clueless on portlets, but from my 'vague consumer' view, I thought the JSR was standardising a lot of what Jetspeed does. A portlet is both different from a servlet and from a taglib. A portlet is mostly servlet-like but with the following additional requirements: - aggregation aware (outputs only code fragments, supports the notion of a portal page context and possible communication between portlets on the same page) - standardized states: for example, Maximized, Minimized, Customization, etc... Not being on the JSR Expert group, I don't have all the details of the forthcoming API but we had long discussions on this subject with the IBM people back in 2000... Are there any Jetspeed people on this JSR? Or is it a competing viewpoint? [much like the Log JSR suddenly wanting to turn Log4j into their reference]. Would Jetspeed use Charon/Pluto, or would the fact that it's an RI limit Jetspeed? Pluto and Jetspeed would have a slightly different scope: - Pluto would be the RI for the JSR 168 API, just like Tomcat is the RI for the Servlet API - Jetspeed would a portal implementation embedding pluto, focussing on building a full-featured portal environment (with things like customization implementation, portal page definition, user preference persistence, etc...) + a set of default portlets. I'm assuming Tomcat and JSTL had a number of Apache people in the JSR, if this one doesn't, then it seems that it's a sourceforge concept. We'd like an open source RI, let's host at Jakarta, they do open-source RI's. Is this not-invented-here-ism or maintaining scope? My main concern at this proposal is that it only apparently covers the RI. What about the API itself ? Is it going to be open-sourced like the Servlet API ? -- Raphaël Luta - [EMAIL PROTECTED] Jakarta Jetspeed - Enterprise Portal in Java http://jakarta.apache.org/jetspeed/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
On Tue, 21 Jan 2003, Luta, Raphael (VUN) wrote: From: Henri Yandell bayard at generationjava.com Is this different from Tomcat and/or JSTL? If so, how? I'm clueless on portlets, but from my 'vague consumer' view, I thought the JSR was standardising a lot of what Jetspeed does. A portlet is both different from a servlet and from a taglib. Sorry. I'm being mis-understood. How is this Ref-implementation different than the situation in which Tomcat and JSTL were reference implementations of JSRs. If it has a substantial difference, ie) no code yet, or no apache developers on the JSR, then I think those differences make a big point as to whether to support the RI of the JSR. Are there any Jetspeed people on this JSR? Or is it a competing viewpoint? [much like the Log JSR suddenly wanting to turn Log4j into their reference]. Would Jetspeed use Charon/Pluto, or would the fact that it's an RI limit Jetspeed? Pluto and Jetspeed would have a slightly different scope: - Pluto would be the RI for the JSR 168 API, just like Tomcat is the RI for the Servlet API - Jetspeed would a portal implementation embedding pluto, focussing on building a full-featured portal environment (with things like customization implementation, portal page definition, user preference persistence, etc...) + a set of default portlets. Okay. So Jetspeed would be limiting itself and maybe not being able to add new features in the JSR area. As in, Tomcat have 'feature' requests which they have to turn down as they aren't in the spec. Same thing for Jakarta Standard Taglib, there are some tag features which can't be done. Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
I realy think JetSpeed could use competition, to make it better. .V Alex McLintock wrote: At 13:38 21/01/03, Stefan Hepper wrote: Hi all, I would like to propose a new Jakarta project, named Pluto, that should provide the reference implementation of the JSR 168 Portlet Specification. Please see http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal for more details (I've also attached the proposal below). My instant reaction was but we already have Jetspeed and then I read There is an agreement with JetSpeed? that the JetSpeed? will be based on this portlet container implementation. Cool. I think I could persuade more people to use Jetspeed if it used a recognised portlet standard. I then read. (3.4) Jyve FAQ (when available) I don't honestly believe that anyone has any interest in fixing Jyve I said I would some time ago, but failed - I don't even know the password for my [EMAIL PROTECTED] login account any more. I know that we are a eat-our-own-dogfood sort of society but I think this is one situation where we ought to admit that Jyve has failed. If I am wrong and there is a community of people willing to make Jyve work again then great. I would be quite happy being wrong about it. As an example I used to maintain a FOP faq with Jyve. Nowadays however I just use a perl script which displays all the submitted entries. Crude, but it works. http://www.OWAL.co.uk/cgi-bin/fopfaq.cgi Alex McLintock Available for java/perl/C++/web development in London, UK or nearby. Apache FOP, Cocoon, Turbine, Struts,XSL:FO, XML, Tomcat, First meeting free.http://www.OWAL.co.uk/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Steven Noels wrote: I was trying not to post the obvious, but yes: this seems largely premature. No code, a restricted community, too much committers coming from one company, I've seen better proposals being fought over lately. Also, possible future integration 'ideas' with some related projects would be comforting (Jetspeed, Tomcat, Struts/Tiles, and the Cocoon portal framework for a starter). Steven, I think these are exactly the sort of questions incubator is designed to answer. Tapestry was about seeing how an existing project can come into Apache. Perhaps Pluto is an opportunity to understand how a new project can be created and encouraged at Apache. They are both interesting challenges for the incubator. As for your issues, No code is true (for now) but that is the sort of project Pluto represents. If at the end, the incubator PMC decides that the project still has the problems you identify (if they are in fact problems), then the project should remain in incubation until the community is self supporting, or be discontinued, whatever. That is a decision for further down the track, I think.It would seem to me that if JetSpeed is in scope for Jakarta, IMHO, a reference implementation at Apache of a Portal standard would be appropriate, especially considering JetSpeed is already at Jakarta. I'm not into portals myself so I can't really comment on the project's merits beyond that. Conor -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New Jakarta proposal: Pluto
Hi, here some more answers to questions that arouse: - 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). - 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. - 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, ... Regards, Stefan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
