You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Steven Noels <st...@outerthought.org> on 2003/01/21 16:03:42 UTC
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 Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: New Jakarta proposal: Pluto
Posted by Sam Ruby <ru...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Sam Ruby <ru...@apache.org>.
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
Re: New Jakarta proposal: Pluto
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
Re: New Jakarta proposal: Pluto
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Santiago Gala <sg...@hisitech.com>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Santiago Gala <sg...@hisitech.com>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Craig R. McClanahan wrote:
<snip/>
Totally! Anyone doing portal work will probably understand the need for
this.
-Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Here's the latest "bad imports" report....
Posted by Tom Copeland <to...@infoether.com>.
...for all the Jakarta projects:
Module LOC Bad imports Pctg
=================================================
jakarta-oro 5777 0 0.00%
jakarta-turbine-torque 8383 1 0.01%
jakarta-struts 15789 4 0.03%
jakarta-turbine-maven 3479 1 0.03%
jakarta-cactus 3476 1 0.03%
jakarta-avalon 1980 1 0.05%
jakarta-ant 48610 80 0.16%
jakarta-bcel 16302 31 0.19%
jakarta-ojb 28367 57 0.20%
jakarta-poi 22529 62 0.28%
jakarta-commons 104407 299 0.29%
jakarta-regexp 1822 6 0.33%
jakarta-james 12171 47 0.39%
jakarta-jmeter 22935 111 0.48%
jakarta-log4j 12021 60 0.50%
jakarta-ecs 17285 88 0.51%
jakarta-turbine-fulcrum 9245 60 0.65%
jakarta-commons-sandbox 110210 925 0.84%
jakarta-ecs2 1414 12 0.85%
jakarta-lucene 5811 59 1.02%
jakarta-taglibs 35848 414 1.15%
jakarta-turbine-jcs 8302 127 1.53%
jakarta-jetspeed 34087 696 2.04%
jakarta-velocity 15630 330 2.11%
jakarta-tomcat-4.0 40557 913 2.25%
jakarta-velocity-dvsl 914 21 2.30%
jakarta-turbine-jyve 4304 99 2.30%
591655 4505 0.76%
And the totals for everyone (i.e., the xml projects also) are listed
here:
http://cvs.apache.org/~tcopeland/jakarta_bad_imports.htm
See ya,
Tom
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Santiago Gala <sg...@hisitech.com>.
Andrew C. Oliver wrote:
> 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
>
I paste here an excertp from a mail in Jetspeed-dev, for people wanting
to know more. You can track the whole thread in:
http://marc.theaimsgroup.com/?t=104315831900002&r=1&w=2
---pasted from Jetspeed-dev---
Luta, Raphael (VUN) wrote:
> De : Weaver, Scott [mailto:Sweaver@rippe.com]
>
>>
>>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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by "Andrew C. Oliver" <ac...@apache.org>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Sam Ruby <ru...@apache.org>.
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.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Costin Manolache <cm...@yahoo.com>.
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>
Re: New Jakarta proposal: Pluto
Posted by Stefan Hepper <st...@hursley.ibm.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 21 Jan 2003, Costin Manolache wrote:
> Date: Tue, 21 Jan 2003 11:31:32 -0800
> From: Costin Manolache <cm...@yahoo.com>
> Reply-To: Jakarta General List <ge...@jakarta.apache.org>
> To: general@jakarta.apache.org
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Costin Manolache <cm...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Santiago Gala <sg...@hisitech.com>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Alex McLintock <al...@OWAL.co.uk>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Costin Manolache <cm...@yahoo.com>.
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 ?
If in a bright future Jakarta will be a single community - having
pluto as a subproject of jetspeed or as a separate jakarta subproject
won't make any difference - the community will be the same.
IMO that would be the best approach. You could still have a separate
CVS ( but hopefully share the mailing list with jetspeed ).
BTW - my understanding is that the spec lead ( or the expert group )
can choose to use an open mailing list - I know at least 2 JSRs that
do that. I think it would be a good policy for apache to favor
JSRs that choose open lists, and avoid closed JSRs.
Costin
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.
>
> - Everyone that wants to help is more than welcome to join
>
> Regards,
> Stefan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Stefan Hepper <st...@hursley.ibm.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Steven Noels <st...@outerthought.org>.
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 Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: New Jakarta proposal: Pluto
Posted by Steven Noels <st...@outerthought.org>.
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 Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Santiago Gala <sg...@hisitech.com>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Sam Ruby <ru...@apache.org>.
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
Re: New Jakarta proposal: Pluto
Posted by Sam Ruby <ru...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Steven Noels <st...@outerthought.org>.
Henri Yandell wrote:
> Is this not-invented-here-ism or maintaining scope?
From my part: scope & fairness.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: New Jakarta proposal: Pluto
Posted by Steven Noels <st...@outerthought.org>.
Henri Yandell wrote:
> Is this not-invented-here-ism or maintaining scope?
From my part: scope & fairness.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: New Jakarta proposal: Pluto
Posted by Henri Yandell <ba...@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.
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
Re: New Jakarta proposal: Pluto
Posted by Henri Yandell <ba...@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.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>