Re: Starting a java specs project (fwd)
Henri Yandell wrote: An FYI. Please kick me if I'm going too far with these ideas; I get the feeling I have a general +0, but hard to tell sometimes. See interspersed. I am not quite to the + point yet, but probably either just missing some concepts / principles or interested in understanding better what the alternatives are. Hen -- Forwarded message -- Date: Tue, 27 Dec 2005 11:42:47 -0500 (EST) From: Henri Yandell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: general@incubator.apache.org Subject: Re: Starting a java specs project One idea was to collate them as a part of Jakarta. My aim for Jakarta is to either promote subprojects to TLP or flatten them into Jakarta Commons, The risk there is j-c becoming the new umbrella. We are also having enough trouble scaling j-c now. leading to a non-umbrella Jakarta It would be great if we could get a consensus on what an umbrella is and what is bad about it. I don't want to open too many cans of worms here; but not all of us were around for the good old bad old days of Jakarta. It seems to me that all of the following could now be considered umbrellas in some sense, but we (apache) seem to be collectively OK with them: Geronimo Web Services XML Struts DB Logging Portals But somehow Jakarta is too big. If you look at all of the code now coming into Geronimo with the incubations in progress, it will be larger than Jakarta currently is soon. So why exactly do we need to either mash, e.g. Hivemind into Commons or move it to TLP? If the answer is PMC oversight then why doesn't that apply to the projects above as well? We have made a lot of progress - mostly thanks to you, Hen - getting adequate PMC representation from all Jakarta projects, so I don't see that as such a big concern any more. So what problem exactly are we trying to solve by pushing things out or mashing them into Commons? I don't mean to be argumentative here, I just want to understand clearly what the goal is and what our acceptable options are. It would be great to have some principles on what kinds of aggregates (euphemism for umbrellas ;-) are OK and what kinds are not. Based on these principles, we might decide to divide Jakarta differently, creating some smaller aggregates rather than one big one (j-c) and a string of small TLPs. (I know, you didn't think you'd see it in your lifetime). This new Jakarta would have the potential to serve two roles: 1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED] 2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons] While j-c might have begun as 2), this is no longer the whole story, or even the main story any more. Storing the spec source there would be good for everyone I think; it would help bring people to Jakarta to share code and conversation, and the Commons community would make good stewards for the code if the various owners departed. We already have too much orphaned code in j-c, IMHO. The advantage of bringing this stuff to j-c would be bringing in some more active and engaged committers. This I am sure we would all welcome. Orphaned code we would not. Maintaining this code will require some specialized expertise most likely concentrated in projects like Geronimo, Tomcat, etc. If committers from these projects are interested and willing to sign up to actively support the code in j-c (including responding to user questions), I am sure we will be happy to have them join us. I would be hesitant to volunteer the j-c community, however, as a support mechanism without ongoing active involvement from the apache projects using the specs, though. Some other pluses are that it would help be a part of an attempt to rejuvenate Jakarta in 2006 (as a kind of federation) and that non-JCP specs could be stored there too. Not trying to intrude on the JCP stuff though, so I can see if it's preferred to keep things under a strictly JCP-oriented environment. Hen On Tue, 27 Dec 2005, Alan D. Cabrera wrote: There has been some discussion on creating a Java specs project which would hold all the specs jars from the various JSRs as well as other standards, e.g. CORBA. Often, there are many duplicate copies of the source code for the same JSR floating around in different Apache projects. It would be a great idea to move them all into one project. This idea, so far, has been met with much enthusiasm. How do we get this started? Regards, Alan - 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: Starting a java specs project (fwd)
Hola, An FYI. Please kick me if I'm going too far with these ideas; I get the feeling I have a general +0, but hard to tell sometimes. Not going too far: these are good ideas IMHO. My aim for Jakarta is to either promote subprojects to TLP or flatten them into Jakarta Commons, leading to a non-umbrella Jakarta (I know, you didn't think you'd see it in your lifetime). This new Jakarta would have the potential to serve two roles: 1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED] 2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons] Why Jakarta Commons and not just Jakarta? I thought either move to a TLP or be a normal jakarta project as the two options, essentially making Jakarta itself a Commons of sorts. Storing the spec source there would be good for everyone I think; it would help bring people to Jakarta to share code and conversation, and the Commons community would make good stewards for the code if the various owners departed. We need to keep in mind that commit access to specific spec modules may be restricted in a manner slightly different than the usual Jakarta way, e.g. to only members of the relevant Expert Group. (For example, not all Tomcat committers can modify jakarta-servletapi-5). Some other pluses are that it would help be a part of an attempt to rejuvenate Jakarta in 2006 (as a kind of federation) and that non-JCP specs could be stored there too. Nice. Some OASIS stuff comes to mind. -- Yoav Shapira System Design and Management Fellow MIT Sloan School of Management Cambridge, MA, USA [EMAIL PROTECTED] / www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Starting a java specs project (fwd)
On Tue, 27 Dec 2005, Phil Steitz wrote: Henri Yandell wrote: An FYI. Please kick me if I'm going too far with these ideas; I get the feeling I have a general +0, but hard to tell sometimes. See interspersed. I am not quite to the + point yet, but probably either just missing some concepts / principles or interested in understanding better what the alternatives are. Answers inline. Thanks for the reply, this is the first time I've probably listed all of these bits together as a strategy, so I apologise for any surprise. -- Forwarded message -- Date: Tue, 27 Dec 2005 11:42:47 -0500 (EST) From: Henri Yandell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: general@incubator.apache.org Subject: Re: Starting a java specs project One idea was to collate them as a part of Jakarta. My aim for Jakarta is to either promote subprojects to TLP or flatten them into Jakarta Commons, The risk there is j-c becoming the new umbrella. We are also having enough trouble scaling j-c now. leading to a non-umbrella Jakarta It would be great if we could get a consensus on what an umbrella is and An umbrella is a joining of disjoint communities under a common TLP. A non-umbrella is one in which the whole project is a part of the same community. That's a nicely grey definition :) It allows for things to be becoming less non-umbrella and more umbrella. ie) Struts now has two subprojects and their concern is to make sure that they stay focused on the one community. what is bad about it. I don't want to open too many cans of worms here; but not all of us were around for the good old bad old days of Jakarta. It seems to me that all of the following could now be considered umbrellas in some sense, but we (apache) seem to be collectively OK with them: Some of the below are definitely listed as 'heading that way', but I don't want to get mired down in that, it's the boards worry as to when they become too much umbrella and too little single-community. Geronimo Web Services XML Struts DB Logging Portals But somehow Jakarta is too big. If you look at all of the code now coming I don't think Jakarta's considered too big anymore. A lot of this is being driven by my wanting to rekindle the positive sides of the old Jakarta, and wanting to finish what was started. It might be the librarian in me, but the current state of Jakarta has no raison d'etre. It's just a clump of legacy. The biggest problem with Jakarta currently is that we've become increasingly disjoint. In many ways we are less healthy than we were 4 years ago. We have less projects, but much less in the way of intersection between communities. We've replaced a 7 person sub-board with a single chair [though there is now quite a clear direction for that single chair]. into Geronimo with the incubations in progress, it will be larger than Jakarta currently is soon. So why exactly do we need to either mash, e.g. Hivemind into Commons or move it to TLP? If the answer is PMC oversight then why doesn't that apply to the projects above as well? We have made a lot of progress - mostly thanks to you, Hen - getting adequate PMC representation from all Jakarta projects, so I don't see that as such a big concern any more. So what problem exactly are we trying to solve by pushing things out or mashing them into Commons? I don't mean to be argumentative here, I just want to understand clearly what the goal is and what our acceptable options are. It would be great to have some principles on what kinds of aggregates (euphemism for umbrellas ;-) are OK and what kinds are not. Based on these principles, we might decide to divide Jakarta differently, creating some smaller aggregates rather than one big one (j-c) and a string of small TLPs. One vibrant community, with a future and a reason to exist. A place for [EMAIL PROTECTED] people to get together and a folding of two (or more) sets of problems [inactivity, innovation, neutral ground] into a single space instead of the current multiple spaces. ie) Jakarta has the same problems with BCEL that Commons has with BeanUtils. (I know, you didn't think you'd see it in your lifetime). This new Jakarta would have the potential to serve two roles: 1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED] 2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons] While j-c might have begun as 2), this is no longer the whole story, or even the main story any more. It's still an important part of the story. Many of our components are being released in Commons because Struts needs updates etc. Storing the spec source there would be good for everyone I think; it would help bring people to Jakarta to share code and conversation, and the Commons community would make good stewards for the code if the various owners departed. We already have too much orphaned code in j-c, IMHO. The advantage of bringing this stuff to j-c would
Re: Starting a java specs project (fwd)
Second FYI, the external to Jakarta part of the specs thread is going on at [EMAIL PROTECTED] Hen On Tue, 27 Dec 2005, Henri Yandell wrote: An FYI. Please kick me if I'm going too far with these ideas; I get the feeling I have a general +0, but hard to tell sometimes. Hen -- Forwarded message -- Date: Tue, 27 Dec 2005 11:42:47 -0500 (EST) From: Henri Yandell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: general@incubator.apache.org Subject: Re: Starting a java specs project One idea was to collate them as a part of Jakarta. My aim for Jakarta is to either promote subprojects to TLP or flatten them into Jakarta Commons, leading to a non-umbrella Jakarta (I know, you didn't think you'd see it in your lifetime). This new Jakarta would have the potential to serve two roles: 1) Place for [EMAIL PROTECTED] to share conversation [EMAIL PROTECTED] 2) Place for [EMAIL PROTECTED] to share code [Jakarta Commons] Storing the spec source there would be good for everyone I think; it would help bring people to Jakarta to share code and conversation, and the Commons community would make good stewards for the code if the various owners departed. Some other pluses are that it would help be a part of an attempt to rejuvenate Jakarta in 2006 (as a kind of federation) and that non-JCP specs could be stored there too. Not trying to intrude on the JCP stuff though, so I can see if it's preferred to keep things under a strictly JCP-oriented environment. Hen On Tue, 27 Dec 2005, Alan D. Cabrera wrote: There has been some discussion on creating a Java specs project which would hold all the specs jars from the various JSRs as well as other standards, e.g. CORBA. Often, there are many duplicate copies of the source code for the same JSR floating around in different Apache projects. It would be a great idea to move them all into one project. This idea, so far, has been met with much enthusiasm. How do we get this started? Regards, Alan - 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]
jakarta future WAS: Re: Starting a java specs project (fwd)
Henri Yandell wrote: snip/ It would be great if we could get a consensus on what an umbrella is and An umbrella is a joining of disjoint communities under a common TLP. A non-umbrella is one in which the whole project is a part of the same community. Nice definition. Thanks. snip/ The biggest problem with Jakarta currently is that we've become increasingly disjoint. In many ways we are less healthy than we were 4 years ago. We have less projects, but much less in the way of intersection between communities. We've replaced a 7 person sub-board with a single chair [though there is now quite a clear direction for that single chair]. Thanks again. So the real problem is disjointness. It seems then that we have three logical alternatives: 0) Full disintegration - all projects (incl j-c) become TLPs or die and Jakarta effectively dies as a concept. 1) Commons or bust - lump small components (e.g. BCEL, ORO) into j-c and move the others (e.g. Tapestry, Jmeter, Cactus) to TLP. Keep jakarta-general around and the Jakarta site for general Java community-building across apache. 2) Re-aggregate - divide Jakarta up into a small number of cohesive aggregates. Its not clear to me how this would work or if this kind of encouraged merging is a good idea; but it is logically the same sort of thing that you are hinting at in 1). 0) seems a shame from the Java community and Jakarta brand (whatever that means) standpoint; but may be the most reasonable thing to do. My concern with 1) is that j-c is already having trouble scaling and I am not so sure that once things are merged in (or out) there is anything substantial left for Jakarta to be (i.e., I am having a hard time seeing the real practical difference between 0) and 1)). I have to confess to having no idea how to do 2), but maybe others in the community do - ideally people working on projects that might want to aggregrate. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta future WAS: Re: Starting a java specs project (fwd)
Hi Phil, On 12/28/05, Phil Steitz [EMAIL PROTECTED] wrote: Thanks again. So the real problem is disjointness. It seems then that we have three logical alternatives: I don't think there is a lot of difference any of these. Jakarta commons as a TLP is basically (1) as well. There are definitely some details to sort out, but they are all along the same track. Thinking more about this, I don't know about pushing things into commons. The important thing is consistent practices, consolidated committers and community, but maybe not the naming. Jakarta BCEL sounds fine to stay that way, as does Jakarta Commons Collections. For scalability, I don't see there is a problem dealing with that in the near future in commons-user or commons-dev (if the notifications from SVN, JIRA, Gump, etc go to a different list). List traffic seems the only barrier here - but I think these are issues to deal with during growth, not up front. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta future WAS: Re: Starting a java specs project (fwd)
On Tue, 27 Dec 2005, Phil Steitz wrote: Henri Yandell wrote: The biggest problem with Jakarta currently is that we've become increasingly disjoint. In many ways we are less healthy than we were 4 years ago. We have less projects, but much less in the way of intersection between communities. We've replaced a 7 person sub-board with a single chair [though there is now quite a clear direction for that single chair]. Thanks again. So the real problem is disjointness. It seems then that we have three logical alternatives: 0) Full disintegration - all projects (incl j-c) become TLPs or die and Jakarta effectively dies as a concept. 1) Commons or bust - lump small components (e.g. BCEL, ORO) into j-c and move the others (e.g. Tapestry, Jmeter, Cactus) to TLP. Keep jakarta-general around and the Jakarta site for general Java community-building across apache. As Brett pointed out, this is really 0). I effectively a) don't want to mess around with the commons.apache.org conversation again and b) think there is a real synergy between Jakarta Commons and Java Federation. 2) Re-aggregate - divide Jakarta up into a small number of cohesive aggregates. Its not clear to me how this would work or if this kind of encouraged merging is a good idea; but it is logically the same sort of thing that you are hinting at in 1). Yep, this is a further idea I'd mentioned somewhere but I forget where. Folding into Commons means an increase in noise, though the ones that would get folded in aren't that noisy. Largely they're ones that members of the Commons community are already juggling, or whose single committer would really benefit from the shared community. However, I think if we find the noise too much, then we can group things. They're categorically not subprojcts, just groupings. HttpClient is already heading this way, it's now the HTTP-Group of Jakarta Components, with a little bit of artistic license on my part :) Silk would be the Web-Group of Jakarta Components [I've been unable to get anything firm on the Silk name, so for the last few weeks I've put it on the backburner as this series of ideas would trump it]. ORO, Regexp and Codec form a natural group. However they're not noisy so they would remain on the commons-dev/commons-user mailing lists. It'd be a bit confusing, but I'd like to set it up so that if a grouping goes quiet, it is directed towards rejoining the main list. We do have a problem with noise, and I think we need to try some new ideas out. Like setting up Jyve at long last :) I sat with a Jyve developer at ApacheCon and he did a good job of answering the usual problems with handling a forum side by side with a mailing list. Another is to come up with a better way of monitoring svn, wiki and jira/bugzilla changes. Maybe we could aggregate them into reports? 0) seems a shame from the Java community and Jakarta brand (whatever that means) standpoint; but may be the most reasonable thing to do. My concern with 1) is that j-c is already having trouble scaling and I am not so sure that once things are merged in (or out) there is anything substantial left for Jakarta to be (i.e., I am having a hard time seeing the real practical difference between 0) and 1)). I have to The big one is the hopeful synergy between Jakarta as a federation and Jakarta as a commons. You can tell I'm in sales mode, I've said that word twice now. On a larger scale, I think this might be a nice pattern for the ASF. Federations who manage just the shared components as a Commons, while also being the shared conversation place. confess to having no idea how to do 2), but maybe others in the community do - ideally people working on projects that might want to aggregrate. There's a bit of that; I'm hoping Cactus and JMeter would form a testing.apache.org if they so choose; but largely I can't see a lot of aggregation reasons. Apart from creating TLPs that are all tiny Commons groupings, which just splits up the parts of shared community we do have. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta future WAS: Re: Starting a java specs project (fwd)
On Wed, 28 Dec 2005, Brett Porter wrote: Thinking more about this, I don't know about pushing things into commons. The important thing is consistent practices, consolidated committers and community, but maybe not the naming. Jakarta BCEL sounds fine to stay that way, as does Jakarta Commons Collections. I was originally thinking it would be more like Jakarta Collections than Jakarta Commons BCEL. But a good point, the naming is not a biggy. It'd be pretty loose I think, the same way Tomcat was Apache Tomcat even while it was still in Jakarta. Commons is a community and a way, rather than just an svn directory. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
