Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On Tue, 2006-04-25 at 22:54 -0700, Martin Cooper wrote: On 4/25/06, Nathan Bubna [EMAIL PROTECTED] wrote: This sounds great, Martin. But if i may be forgiven a little semantic nitpicking, my understanding of previous discussions is that JWC would be a grouping rather than a sub-project. So Tiles would be directly a Jakarta sub-project, rather than a sub-sub-project (i.e. becoming Jakarta Tiles, not Jakarta Web Components Tiles). Yes, you are correct, Tiles would be a Jakarta sub-project within the JWC grouping. I guess I was trying to simplify the proposal for those who haven't paid as much attention to the whole grouping thing, but in retrospect, that probably wasn't such a great idea. ;-) i'd prefer to move away from the term sub-project since it has negative formal associations. it can't be a project mini-me with formal structure of it's own. just a Jakarta component: separate product, same project, same formal organisational structure. AIUI (and it might be a good idea to check this out with PR) the naming guidelines mean that it should be Apache Tiles (not Jakarta Tiles or Jakarta Web Components Tiles). the reason for this is to ensure we can use trademark law to protect ourselves (if that's ever needed). IHMO Apache Tiles from the Jakarta Web Components team sounds pretty good anyway - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On Wed, 2006-04-26 at 14:55 -0500, Greg Reddin wrote: Sorry to be a latecomer to this thread. I've had some trouble subscribing for whatever reason. But I just wanted to add that I am working on Standalone Tiles over at the Struts project and am willing to support it if it's moved to some Jakarta subproject. cool :) I'll let you guys hash out how the community is structured :-) I haven't participated in Jakarta enough lately to have an opinion. i'd hope we're not trying to structure the community, just the formal organisation supporting it. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On Wed, 2006-04-26 at 11:48 -0400, Henri Yandell wrote: The Web Components thread is much older than the recent set of threads, it was back in 2005. So I don't think we've heard your reasons against a JWC Sub-Project as opposed to the not-community-of-community threads. i have worries about any more formal sub-projects: they are too much like project mini-me's with their own formal structure. IMO the legal and formal structures are best aligned. i do like the idea of a JWC grouping or community within jakarta. with all the trappings that the old sub-projects had (mailing lists, web site and so on) but no separate classes of committers under the same pmc. i think a manifesto would be needed for each grouping (somewhere between guidelines and a charter) which should define the scope. I can find this on wiki: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents which includes a charter - though I think the charter needs changing as that's a copy of the Commons charter which is 5% charter and 95% developer guidelines. IIRC the document on the wiki was intended to be the starting point for a charter. I know we voted on the name, I thought we voted on the creation of the subproject as part of that but would need to check archives. Will do that in a bit. i seem to recall a vote but not sure what it was on... On Wed, 26 Apr 2006, Andrew C. Oliver wrote: No. There isn't a consensus. andrew's right that since he dissents, there isn't an absolute consensus. i do suspect that he's views are in the minority, though. we should push things forward until we have something concrete to vote on. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
No. There isn't a consensus. Just you guys REALLY REALLY want it to happen. Do not mistake one for the other. I did pay attention. Yet feel the issue has not been sufficiently addressed thus I'm -1 for all the previously stated reasons in all of the vaguely alluded to threads for all the reasons stated previously that I still feel are not addressed. -Andy Martin Cooper wrote: On 4/25/06, Andrew C. Oliver [EMAIL PROTECTED] wrote: I'd be against another commons style sub-community. Unless you can show me a defined scope, web components means nothing, then expect my objection. Understood. A formal scope does need to be written down and agreed upon. However, I believe that concensus on the gist of such a scope has already happened, between the lines, in the numerous previous threads on JWC on various lists. -- Martin Cooper -Andy James Mitchell wrote: I believe that this would be a great way to bootstrap this new community. If this were a formal vote, then I, as both a Struts PMC and a Jakarta PMC member, would throw a binding +1 your way. -- James Mitchell On Apr 24, 2006, at 11:56 PM, Martin Cooper wrote: There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub-project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub-project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub-project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
The Web Components thread is much older than the recent set of threads, it was back in 2005. So I don't think we've heard your reasons against a JWC Sub-Project as opposed to the not-community-of-community threads. I can find this on wiki: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents which includes a charter - though I think the charter needs changing as that's a copy of the Commons charter which is 5% charter and 95% developer guidelines. I know we voted on the name, I thought we voted on the creation of the subproject as part of that but would need to check archives. Will do that in a bit. Hen On Wed, 26 Apr 2006, Andrew C. Oliver wrote: No. There isn't a consensus. Just you guys REALLY REALLY want it to happen. Do not mistake one for the other. I did pay attention. Yet feel the issue has not been sufficiently addressed thus I'm -1 for all the previously stated reasons in all of the vaguely alluded to threads for all the reasons stated previously that I still feel are not addressed. -Andy Martin Cooper wrote: On 4/25/06, Andrew C. Oliver [EMAIL PROTECTED] wrote: I'd be against another commons style sub-community. Unless you can show me a defined scope, web components means nothing, then expect my objection. Understood. A formal scope does need to be written down and agreed upon. However, I believe that concensus on the gist of such a scope has already happened, between the lines, in the numerous previous threads on JWC on various lists. -- Martin Cooper -Andy James Mitchell wrote: I believe that this would be a great way to bootstrap this new community. If this were a formal vote, then I, as both a Struts PMC and a Jakarta PMC member, would throw a binding +1 your way. -- James Mitchell On Apr 24, 2006, at 11:56 PM, Martin Cooper wrote: There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub-project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub-project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub-project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
Sorry to be a latecomer to this thread. I've had some trouble subscribing for whatever reason. But I just wanted to add that I am working on Standalone Tiles over at the Struts project and am willing to support it if it's moved to some Jakarta subproject.I'll let you guys hash out how the community is structured :-) I haven't participated in Jakarta enough lately to have an opinion. Greg On Apr 26, 2006, at 10:48 AM, Henri Yandell wrote: The Web Components thread is much older than the recent set of threads, it was back in 2005. So I don't think we've heard your reasons against a JWC Sub-Project as opposed to the not-community- of-community threads. I can find this on wiki: http://wiki.apache.org/jakarta/CreatingCommonsForWebComponents which includes a charter - though I think the charter needs changing as that's a copy of the Commons charter which is 5% charter and 95% developer guidelines. I know we voted on the name, I thought we voted on the creation of the subproject as part of that but would need to check archives. Will do that in a bit. Hen On Wed, 26 Apr 2006, Andrew C. Oliver wrote: No. There isn't a consensus. Just you guys REALLY REALLY want it to happen. Do not mistake one for the other. I did pay attention. Yet feel the issue has not been sufficiently addressed thus I'm -1 for all the previously stated reasons in all of the vaguely alluded to threads for all the reasons stated previously that I still feel are not addressed. -Andy Martin Cooper wrote: On 4/25/06, Andrew C. Oliver [EMAIL PROTECTED] wrote: I'd be against another commons style sub-community. Unless you can show me a defined scope, web components means nothing, then expect my objection. Understood. A formal scope does need to be written down and agreed upon. However, I believe that concensus on the gist of such a scope has already happened, between the lines, in the numerous previous threads on JWC on various lists. -- Martin Cooper -Andy James Mitchell wrote: I believe that this would be a great way to bootstrap this new community. If this were a formal vote, then I, as both a Struts PMC and a Jakarta PMC member, would throw a binding +1 your way. -- James Mitchell On Apr 24, 2006, at 11:56 PM, Martin Cooper wrote: There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub-project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub- project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub-project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
I believe that this would be a great way to bootstrap this new community. If this were a formal vote, then I, as both a Struts PMC and a Jakarta PMC member, would throw a binding +1 your way. -- James Mitchell On Apr 24, 2006, at 11:56 PM, Martin Cooper wrote: There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub- project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub- project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub- project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
This sounds great, Martin. But if i may be forgiven a little semantic nitpicking, my understanding of previous discussions is that JWC would be a grouping rather than a sub-project. So Tiles would be directly a Jakarta sub-project, rather than a sub-sub-project (i.e. becoming Jakarta Tiles, not Jakarta Web Components Tiles). I do also like Andrew's term sub-community as that describes the true intent of having these groupings. As far as a formal scope to be attached to the Jakarta Web Components group goes, i would propose that members of the JWC should be java components developed primarily for use in the development of web applications. On 4/24/06, Martin Cooper [EMAIL PROTECTED] wrote: There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub-project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub-project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub-project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? -- Martin Cooper [1] http://struts.apache.org/struts-action/struts-tiles/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On 4/25/06, Andrew C. Oliver [EMAIL PROTECTED] wrote: I'd be against another commons style sub-community. Unless you can show me a defined scope, web components means nothing, then expect my objection. Understood. A formal scope does need to be written down and agreed upon. However, I believe that concensus on the gist of such a scope has already happened, between the lines, in the numerous previous threads on JWC on various lists. -- Martin Cooper -Andy James Mitchell wrote: I believe that this would be a great way to bootstrap this new community. If this were a formal vote, then I, as both a Struts PMC and a Jakarta PMC member, would throw a binding +1 your way. -- James Mitchell On Apr 24, 2006, at 11:56 PM, Martin Cooper wrote: There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub-project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub-project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub-project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Tiles as the seed for Jakarta Web Components
On 4/25/06, Nathan Bubna [EMAIL PROTECTED] wrote: This sounds great, Martin. But if i may be forgiven a little semantic nitpicking, my understanding of previous discussions is that JWC would be a grouping rather than a sub-project. So Tiles would be directly a Jakarta sub-project, rather than a sub-sub-project (i.e. becoming Jakarta Tiles, not Jakarta Web Components Tiles). Yes, you are correct, Tiles would be a Jakarta sub-project within the JWC grouping. I guess I was trying to simplify the proposal for those who haven't paid as much attention to the whole grouping thing, but in retrospect, that probably wasn't such a great idea. ;-) I do also like Andrew's term sub-community as that describes the true intent of having these groupings. As far as a formal scope to be attached to the Jakarta Web Components group goes, i would propose that members of the JWC should be java components developed primarily for use in the development of web applications. That's a good start. I'm not sure it's enough, but we could start from there. -- Martin Cooper On 4/24/06, Martin Cooper [EMAIL PROTECTED] wrote: There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub-project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub-project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub-project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? -- Martin Cooper [1] http://struts.apache.org/struts-action/struts-tiles/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Tiles as the seed for Jakarta Web Components
There has been considerable discussion, on this list and others, about the creation of a Jakarta Web Components sub-project (also previously known as Jakarta Silk). I believe the concensus has been in favour of creating it. However, we seemed to get bogged down, several times, in discussions of the name, or of exactly which pieces of Jakarta Commons, Jakarta Taglibs, etc., should move to the new sub-project. Meanwhile, over at Struts, we have had a number of discussions about the future of Tiles[1], currently a Struts sub-project. We have been working hard to make Tiles independent of Struts, and are close to achieving that goal. With Tiles no longer depending on Struts, it makes little sense for it to remain a part of the Struts project. In fact, it is much more likely to flourish outside of Struts. The proposal, then, is to create the Jakarta Web Components sub-project, and make Tiles the first citizen of that sub-project. This simultaneously achieves several objectives: 1) We actually get started with the Jakarta Web Components sub-project. 2) We can defer discussion of which other parts of Jakarta move there. 3) We create a logical home for the now-Struts-independent Tiles. While Tiles is a powerful templating framework, it is actually a fairly small code base, making it a good candidate for an independent web component. It is still being developed, so we would not be seeding Jakarta Web Components with a dormant component. Several of the Struts committers (many of whom are already Jakarta committers) would come here to continue working on Tiles, and to help build the Jakarta Web Components sub-project. Once Jakarta Web Components is up and running, it would, of course, be up to the various communities surrounding Commons and Taglibs components, and potentially other Jakarta sub-projects, as to whether or not they choose to join the new sub-project. The goal of this proposal is simply to seed the sub-project and get the ball rolling. Comments? -- Martin Cooper [1] http://struts.apache.org/struts-action/struts-tiles/
Re: Jakarta Web Components
On Mon, 2006-03-06 at 19:49 +0100, Ortwin Glück wrote: Sandy McArthur wrote: As a programmer looking for useful code to help me with uploaded files, I'm going to look in something named Jakarta *Web* Components first. When I see Jakarta HTTP Components I think of interacting with the HTTP protocol. I know FileUpload does both, but when I'm writing an webapp I think I'm working with a *web* app first and while I am working with HTTP it is a secondary concern. -- Sandy McArthur This may be true, but it shouldn't influence how the communities around the code are organised. This is more a matter of communication and branding. i think that's one of the advantages of flattening karma and voting: . we need to separate the formal legal structure (karma, voting) from the community (developers hanging out) from the ontological (communicating that the components are). from an ontological perspective, fileupload needs to be tagged as both http and web component with a sideways relationship to codec. from a community perspective, martin feels more at home with the httpclient team and it sounds like there are sound reasons to believe development might be more progressive. from a legal perspective, we're all jakarta: karma and voting need to be communal. in some ways, we need to find a way since the whole of apache is going to be facing these problems soon... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
robert burrell donkin wrote: i think that's one of the advantages of flattening karma and voting: . we need to separate the formal legal structure (karma, voting) from the community (developers hanging out) from the ontological (communicating that the components are). from an ontological perspective, fileupload needs to be tagged as both http and web component with a sideways relationship to codec. from a community perspective, martin feels more at home with the httpclient team and it sounds like there are sound reasons to believe development might be more progressive. from a legal perspective, we're all jakarta: karma and voting need to be communal. in some ways, we need to find a way since the whole of apache is going to be facing these problems soon... - robert You are speaking from deep in my heart (or stomach). These are four different views of the same thing. The question is how we can address all four of them. I am deliberately not posing the if question :) Ortwin Glück - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
Hola, From Commons: * EL (dormant?) Tricky status here, and here's why: the JSP 2.1 spec has EL changes, and they're significant enough that Jacob Hookum did an almost cleanroom implementation of EL. He's a newly-elected Tomcat committer (Tomcat 6 will support JSP 2.1) and is in the process of donating the EL implementation to Tomcat technically. It's going to live on its own within the Tomcat repository, as we'd like to modularize things further in Tomcat 6 and he'd like to make the EL impl usable by other servers (Glassfish is already using it or will in the near future). In light of that, I'm not sure what commons-el should do. Maybe move into the Tomcat repo? Maybe instead of hosting the new EL in Tomcat we should move it to Web Components along with the old commons-EL? * FileUpload (active, martinc should confirm interest in moving to JWC) Seems like the classic web component to me ;) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) Right, but we should keep the repositories together, so if 2.0 moves to Web Components, so should 1.1/1.2 taglibs. Yoav -- Yoav Shapira Senior Architect Nimalex LLC 1 Mifflin Place, Suite 310 Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On Mon, 6 Mar 2006, Yoav Shapira wrote: Hola, From Commons: * EL (dormant?) Tricky status here, and here's why: the JSP 2.1 spec has EL changes, and they're significant enough that Jacob Hookum did an almost cleanroom implementation of EL. He's a newly-elected Tomcat committer (Tomcat 6 will support JSP 2.1) and is in the process of donating the EL implementation to Tomcat technically. It's going to live on its own within the Tomcat repository, as we'd like to modularize things further in Tomcat 6 and he'd like to make the EL impl usable by other servers (Glassfish is already using it or will in the near future). In light of that, I'm not sure what commons-el should do. Maybe move into the Tomcat repo? Maybe instead of hosting the new EL in Tomcat we should move it to Web Components along with the old commons-EL? * FileUpload (active, martinc should confirm interest in moving to JWC) Seems like the classic web component to me ;) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) Right, but we should keep the repositories together, so if 2.0 moves to Web Components, so should 1.1/1.2 taglibs. +1 - with an aggressive application of dormant/inactive/whatever-label. Most of them are pretty much dead - some architectually, and some just in terms of community. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On 3/6/06, Yoav Shapira [EMAIL PROTECTED] wrote: Hola, From Commons: * EL (dormant?) Tricky status here, and here's why: the JSP 2.1 spec has EL changes, and they're significant enough that Jacob Hookum did an almost cleanroom implementation of EL. He's a newly-elected Tomcat committer (Tomcat 6 will support JSP 2.1) and is in the process of donating the EL implementation to Tomcat technically. It's going to live on its own within the Tomcat repository, as we'd like to modularize things further in Tomcat 6 and he'd like to make the EL impl usable by other servers (Glassfish is already using it or will in the near future). snip/ Thanks for the update. I was aware of that, I sometimes read tc-dev when things of interest pop up. In light of that, I'm not sure what commons-el should do. Maybe move into the Tomcat repo? Maybe instead of hosting the new EL in Tomcat we should move it to Web Components along with the old commons-EL? snap/ Seems like a decision for the Tomcat PMC. I understand there is some interest in keeping 2.1 EL in the TC repository, and maybe potentially having its own release cycle. But thats hearsay, please update us when a decision is made. * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) Right, but we should keep the repositories together, so if 2.0 moves to Web Components, so should 1.1/1.2 taglibs. snip/ Sounds good, I was waiting for someone else to nudge me on this. So, *all* taglibs will be moved, with a suitable application of Hen's disclaimer. -Rahul Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. -- Martin Cooper Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On Mon, 6 Mar 2006, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Seems bogged down in between states at the moment. * Latka (dormant) This should be in Jakarta Sandbox I think. * FeedParser (possibly? dormant) Jakarta Sandbox again. From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. Taglibs Sandbox should just fold in with the Commons Sandbox into a single sandbox for all of the Jakarta bits. Released stuff... back to the old question on what to do with that. Move it to JWC but then identify it as dead? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
Henri Yandell wrote: On Mon, 6 Mar 2006, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Seems bogged down in between states at the moment. There is a prelimiary new site at: http://people.apache.org/~olegk/httpcomponents/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components + Jakarta HttpComponents
On Mon, 2006-03-06 at 10:14 -0800, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Hello, Martin et al There's already plenty of code to look at in SVN. We are gradually moving toward releasing our first official ALPHA. The preview of the HJC web site can be found here: http://people.apache.org/~olegk/httpcomponents/ May I, however, express my (humble) opinion that some of the Commons [FileUpload] code may find a better home in Commons [Codec]. To me, all the mime/multipart parsing logic clearly belongs to [Codec]. There are plans to factor out all multipart encoding code from Commons [HttpClient] and move it to Commons [Codec] This said, Commons [FileUpload] is welcome to consider joining JHC Cheers, Oleg * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. -- Martin Cooper Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components + Jakarta HttpComponents
On 3/6/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Mon, 2006-03-06 at 10:14 -0800, Martin Cooper wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: On 3/6/06, Henri Yandell [EMAIL PROTECTED] wrote: (feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) snip/ But do it within a reasonable time frame (atleast post any objections to JWC in a week -- I think thats reasonable, unless anyone wants more time?). I have been meaning to add some initial components to JWC and begin work there, and while I agree that the name is important, this name game is now getting old ;-) Recap - We had 3 votes for JWC in the initial vote thread, and there seems to have been more added informally on parallel conversations on commons-dev. Seems the J*C trend is catching on (see Stephen talk about JLC in another thread). Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). snap/ Allow me to informally assemble the beginnings of a roster, hopefully others can add/remove. From Commons: * EL (dormant?) * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) Hello, Martin et al There's already plenty of code to look at in SVN. We are gradually moving toward releasing our first official ALPHA. The preview of the HJC web site can be found here: http://people.apache.org/~olegk/httpcomponents/ May I, however, express my (humble) opinion that some of the Commons [FileUpload] code may find a better home in Commons [Codec]. To me, all the mime/multipart parsing logic clearly belongs to [Codec]. There are plans to factor out all multipart encoding code from Commons [HttpClient] and move it to Commons [Codec] This said, Commons [FileUpload] is welcome to consider joining JHC i wondered if we wouldn't see a lot of discussions like this. hard lines have always been hard to draw. is it possible to have multiple associations? some sort of tagging system, with labels instead of folders? Cheers, Oleg * Latka (dormant) * FeedParser (possibly? dormant) From Taglibs: * Reusable Dialog Components (RDC) (JSP 2.0, active) * Others per interest (I have little interest in JSP 1.1/1.2 taglibs, been on 2.0 for a while now) I used to work on the Mailer taglib, but abandoned it when someone else decided to reinvent that as a Mailer2 taglib. That now appears to have been abandoned as well, and never made it out of the Taglibs sandbox. So I'm not sure which, if either, would go to JWC. -- Martin Cooper Then there is the question of sandbox. There has been talk about a Jakarta sandbox, that probably deserves its own thread. -Rahul Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
On 3/6/06, Martin Cooper [EMAIL PROTECTED] wrote: On 3/6/06, Rahul Akolkar [EMAIL PROTECTED] wrote: * FileUpload (active, martinc should confirm interest in moving to JWC) I'm not so sure about this. FileUpload has already cloned some code from HttpClient, and could undoubtedly make use of more. Its purpose is to parse HTTP requests. So I'm actually more inclined to move this to Jakarta HTTP Components, assuming that HttpClient eventually morphs into that. (I thought it had already, but I can't seem to find a JHC anywhere.) As a programmer looking for useful code to help me with uploaded files, I'm going to look in something named Jakarta *Web* Components first. When I see Jakarta HTTP Components I think of interacting with the HTTP protocol. I know FileUpload does both, but when I'm writing an webapp I think I'm working with a *web* app first and while I am working with HTTP it is a secondary concern. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components + Jakarta HttpComponents
On 3/6/06, Nathan Bubna [EMAIL PROTECTED] wrote: On 3/6/06, Oleg Kalnichevski [EMAIL PROTECTED] wrote: May I, however, express my (humble) opinion that some of the Commons [FileUpload] code may find a better home in Commons [Codec]. To me, all the mime/multipart parsing logic clearly belongs to [Codec]. There are plans to factor out all multipart encoding code from Commons [HttpClient] and move it to Commons [Codec] This said, Commons [FileUpload] is welcome to consider joining JHC i wondered if we wouldn't see a lot of discussions like this. hard lines have always been hard to draw. is it possible to have multiple associations? some sort of tagging system, with labels instead of folders? It's not important how something is implemented, what is important is what it does. Our end users (programmers) don't care that lib Foo used lib Bar. They just care what it does. When categorizing this stuff pretend you are an end user. A lib's existence is justified by how it helps it's users get work done. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jakarta Web Components
Sandy McArthur wrote: As a programmer looking for useful code to help me with uploaded files, I'm going to look in something named Jakarta *Web* Components first. When I see Jakarta HTTP Components I think of interacting with the HTTP protocol. I know FileUpload does both, but when I'm writing an webapp I think I'm working with a *web* app first and while I am working with HTTP it is a secondary concern. -- Sandy McArthur This may be true, but it shouldn't influence how the communities around the code are organised. This is more a matter of communication and branding. -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jakarta Web Components
(feel free to keep discussing names etc, but for the moment I'm going to go ahead with the one above) Would anyone like to start putting together a list of constituent parts for JWC? Please include a proposal for what will happen to any subprojects left dead by the creation of JWC (ie: Taglibs). Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
