Re: Now what? (was: Jakarta Overview)
Philipp K. Janert [EMAIL PROTECTED] wrote on 23/03/2002 09:47:31 AM: [snip] I don't think documentation is marketing - and what I tried to provide is simply documentation, not different in principle than Javadoc, only at a higher level. Except it also contained words such as immature, which border on the emotional. [snip] - Users vs Developers I sense a certain ambivalence towards making Jakarta projects easier to use - Ted, for instance, points out that more users lead I'll take personal exception to that comment. My first patches to a Jakarta project included documentation, and it's one of the main things I've done on Latka at this point. I think we'd all like the projects to be easier to use and understand, but I'll wager not everyone is comfortable that they can do it themselves. [snip] [snip] That's great! The News section has also disappeared - I consider that a bit sad: I think some measure for the activity of the project would be helpful, but there may be better ways to determine it. I would have thought that the date of the most recent release would not be considered a subjective judgement. 'News' as a measure of activity on a project is effectively useless. Commits/month would be a lot better. Given most jakarta projects have a nightly build, releases by themselves aren't as much of a milestone as people would think from the commercial point of view. Take Struts for example. I happily built production systems off pre-1.0 code for many months. There were no new betas, just updated nightly builds. The code was actively being developed, but why waste time on a release if there's no particular purpose? The question is: Now what? Should we: - collect suggestions to improve the initial draft so that the majority here considers it a good thing to have and develop it further along those line? - leave it as is? - drop it altogether? - replace it with something altogether different? Well, it's already being improved by being changed in CVS, and could easily be replaced with something altogether different over time. I'd much rather see the commons stuff removed and a pointer in place to the existing page, and some form of 'activity' in place of what was news. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://www.multitask.com.au/developers
RE: Now what? (was: Jakarta Overview)
- Audience and Marketing: Specifically, it is directed towards users, who hope to find something useful for their own projects. (Those users may turn into contributors over time!) It takes too much effort to support a user base for a project that changes rapidly (ie any 'alpha' status code). Hence these parts are not advertised very well. It should stay that way. I cannot understand why Leo and Ceki refer to the document (and, by implication, others like it) as Marketing - a term which carries in this context clearly condescending connotations. as dion said. When a project you are working on very hard for a long time is listed as immature or something like that, it is very hard to find the right wording for a response. - Users vs Developers again, I personally distinguish between alpha, beta and final releases. You only offer support (answers to mailing list questions) for released products. - Personal Assessment and Maintenance: In terms of maintenance: Once everything is set up, this should not take too much effort (just updates of revision numbers and release dates, really). I think I also hinted (cough) that I might be willing to help with that (to the degree that I have available resources, of course) provided that maintaining such an overview document at all is solidly supported by the community. as we say: documentation is always welcome! Now what? = The News section has also disappeared - I consider that a bit sad: I think some measure for the activity of the project would be helpful, but there may be better ways to determine it. I would have thought that the date of the most recent release would not be considered a subjective judgement. it's simply not a good indicator. FA, almost nothing happens over at Avalon Framework, but it gets more releases than the way more busy other Avalon parts because it is, well, released. Should we: - collect suggestions to improve the initial draft so that the majority here considers it a good thing to have and develop it further along those line? - leave it as is? - drop it altogether? - replace it with something altogether different? it should, -- after consent by others here -- be merged with the current overview on the front page. That's imho, of course. greetz, - Leo Simons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Now what? (was: Jakarta Overview)
On Fri, 2002-03-22 at 17:47, Philipp K. Janert wrote: Dear Friends! First off, many thanks to Ted for posting my Draft Jakarta Overview, thus allowing everyone to review it, and many thanks to all who provided feedback on it, for or against. I would like to comment on some of the issues raised. - Purpose and Redundancy: To clarify the intended purpose of the document, it may help to explain how it came about: When I started to hang around the Jakarta website, my first desire was to get a good, high-level overview, so that I would then know where to dig deeper into those projects which are relevant to me. I followed every link on the main page to each individual project's homepage, and then on to the sub-projects where appropriate, compiling exactly the information in the submitted document. Took me several days. Assuming that others will have the same experience (and Chris' and Endre's emails seem to indicate they do), I decided to make it available.Just having all the information in one place can help a lot! (The overview on the Jakarta homepage, although great, does not contain either subprojects, or status information.) Agreed, except I don't think your subjective comments are necessarily appropriate for a top level page. Its unlikely that in several days you have been able to objectively judge the status of all the projects. Such information is the responsibility of those project committers. - Audience and Marketing: The document is directed towards people who may not be familiar with all the projects that exist under the Jakarta umbrella. Specifically, it is directed towards users, who hope to find something useful for their own projects. (Those users may turn into contributors over time!) I cannot understand why Leo and Ceki refer to the document (and, by implication, others like it) as Marketing - a term which carries in this context clearly condescending connotations. I don't think documentation is marketing - and what I tried to provide is simply documentation, not different in principle than Javadoc, only at a higher level. It is also simply not true, as Ceki believes, that everybody knows Jakarta: from the inside it may be hard to conceive how large and confusing the entire Jakarta project can appear to the outsider. Agreed. I think the marketing came out of someone else's comments as the discussion went on. - Users vs Developers I sense a certain ambivalence towards making Jakarta projects easier to use - Ted, for instance, points out that more users lead to more support questions (and mailing list discussions, such as this one). But isn't this stance slightly contradictory? If you don't want users, why publish your products? (By the way, I, as a user, am grateful that you do make them public - and that's why I am trying to support this project where I believe it needs it!) Just for balance, Endre puts usability first - I guess, it's a balancing act. In general, Jakarta committers vastly underestimate the importance of a wide audience. I like what Eric Raymond has to say on the subject in the Cathedral and the bazzar. Your users are your testers. Producing quality software requires a massive real world validation. (At least for something like POI, I could never hope to amass the data that users have provided). And as you mention are your pool of new recruits. For all of the time they swear they don't want users...if you watch you'll see them constantly campaign people USE their pet projects. So this is IMHO a paper-tiger party line. - Hello, World and Javadoc: Danny suspects that I have a downer on Javadocs. That is not quite correct. I think Javadocs are great - as a reference. I think they are terrible for just finding out what a project is all about. Overview, Tutorial, Reference: three very different things! I would like to repeat my conviction that for first-time users (and all of us are at that stage at some point in our lives!) worked examples would be immensely helpful in understanding the scope and purpose of each project. It would be great if this could come either out of the projects themselves, or from the larger user community. It is great to see Andrew encourage contribution of documentation to individual projects. I totally agree. I have a downer on Javadocs. Javadocs are the bare minimum that should be provided. They are NOT documentation they are published comments. API docs are less then sufficient, they are the pungent glue that real documentation should be pasted upon. Any project that says the Javadoc is its documentation, I consider not ready for prime-time. That being said, I take an action approach to this. As I have time I contribute documentation to projects that I see that don't meet my documentation requirements for use. - Personal Assessment and Maintenance: Several people pointed out that the document contains subjective
Re: Now what? (was: Jakarta Overview)
On Sat, 2002-03-23 at 03:42, [EMAIL PROTECTED] wrote: Philipp K. Janert [EMAIL PROTECTED] wrote on 23/03/2002 09:47:31 AM: [snip] I don't think documentation is marketing - and what I tried to provide is simply documentation, not different in principle than Javadoc, only at a higher level. Except it also contained words such as immature, which border on the emotional. I don't think he meant any harm. [snip] - Users vs Developers I sense a certain ambivalence towards making Jakarta projects easier to use - Ted, for instance, points out that more users lead I'll take personal exception to that comment. My first patches to a Jakarta project included documentation, and it's one of the main things I've done on Latka at this point. I think we'd all like the projects to be easier to use and understand, but I'll wager not everyone is comfortable that they can do it themselves. I get the same feeling often. Granted I think its probably part that most developers don't feel comfortable with their writing skills. [snip] [snip] That's great! The News section has also disappeared - I consider that a bit sad: I think some measure for the activity of the project would be helpful, but there may be better ways to determine it. I would have thought that the date of the most recent release would not be considered a subjective judgement. 'News' as a measure of activity on a project is effectively useless. Commits/month would be a lot better. Hummm...I'll put that comment in the pile of the most important activity in software development is programming pile of things I disagree with. Given most jakarta projects have a nightly build, releases by themselves aren't as much of a milestone as people would think from the commercial point of view. Take Struts for example. I happily built production systems off pre-1.0 code for many months. There were no new betas, just updated nightly builds. The code was actively being developed, but why waste time on a release if there's no particular purpose? Whoa...dude.. The release is the point when all the edges are smoothed and things are tied off. Release often. There is a difference between a build and a release. Its the point when an effort is made to make sure the documentation matches up and everything is *ready*. It a tracking point in the software lifecycle. If you never stop the bus then when can you paint it? The question is: Now what? Should we: - collect suggestions to improve the initial draft so that the majority here considers it a good thing to have and develop it further along those line? - leave it as is? - drop it altogether? - replace it with something altogether different? Well, it's already being improved by being changed in CVS, and could easily be replaced with something altogether different over time. I'd much rather see the commons stuff removed and a pointer in place to the existing page, and some form of 'activity' in place of what was news. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://www.multitask.com.au/developers -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Now what? (was: Jakarta Overview)
At 14:47 22.03.2002 -0800, you wrote: - Audience and Marketing: The document is directed towards people who may not be familiar with all the projects that exist under the Jakarta umbrella. Specifically, it is directed towards users, who hope to find something useful for their own projects. (Those users may turn into contributors over time!) I cannot understand why Leo and Ceki refer to the document (and, by implication, others like it) as Marketing - a term which carries in this context clearly condescending connotations. I don't think documentation is marketing - and what I tried to provide is simply documentation, not different in principle than Javadoc, only at a higher level. I realize that you spent considerable amount of time editing the document. I appreciate the effort. I assure you that there is no condescension on my part, at least not intentional. The introduction in your email came through as here is the solution to all Jakarta's problems. I have a hard time accepting that as being the truth. It is also simply not true, as Ceki believes, that everybody knows Jakarta: from the inside it may be hard to conceive how large and confusing the entire Jakarta project can appear to the outsider. The Jakarta brand is very well known. What is less known are the individual Jakarta subprojects, in particular their relation with each other. I doubt the overview document will solve that conundrum. As I said in my previous comments, I do not have a problem with the contents of the document per se but the sprit in which it was presented. IMO, it would have been preferable to work with each individual subproject rather than start a new body of work but that was not my decision to make. Are you willing to continue maintaining it? Make sure that it is comprehensive, consistent and up to date? What will happen when you grow tired of it? Nothing is preventing you from continuing to work on the overview. If you persist, my -1 will be withdrawn or overridden. What is certain is that the overview is yet another brick on of the edifice of Jakarta. Philipp K. Janert, Ph.D. [EMAIL PROTECTED] -- Ceki My link of the month: http://java.sun.com/aboutJava/standardization/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Now what? (was: Jakarta Overview)
Andrew C. Oliver [EMAIL PROTECTED] wrote on 24/03/2002 12:39:09 AM: 'News' as a measure of activity on a project is effectively useless. Commits/month would be a lot better. Hummm...I'll put that comment in the pile of the most important activity in software development is programming pile of things I disagree with. Fine, but since commits aren't just programming, they're also docs, proposals etc, i feel it's a far more valid measure of activity than writing a news article. Given most jakarta projects have a nightly build, releases by themselves aren't as much of a milestone as people would think from the commercial point of view. Take Struts for example. I happily built production systems off pre-1.0 code for many months. There were no new betas, just updated nightly builds. The code was actively being developed, but why waste time on a release if there's no particular purpose? Whoa...dude.. The release is the point when all the edges are smoothed and things are tied off. Release often. There is a difference between a build and a release. Its the point when an effort is made to make sure the documentation matches up and everything is *ready*. It a tracking point in the software lifecycle. If you never stop the bus then when can you paint it? I agree, but you need a purpose for a release. Releasing just so it happens often is pointless. There should be a consistent amount of change/bug fixing/docs etc for a release to be made. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://www.multitask.com.au/developers
Re: Now what? (was: Jakarta Overview)
On Sat, 2002-03-23 at 17:38, [EMAIL PROTECTED] wrote: Andrew C. Oliver [EMAIL PROTECTED] wrote on 24/03/2002 12:39:09 AM: 'News' as a measure of activity on a project is effectively useless. Commits/month would be a lot better. Hummm...I'll put that comment in the pile of the most important activity in software development is programming pile of things I disagree with. Fine, but since commits aren't just programming, they're also docs, proposals etc, i feel it's a far more valid measure of activity than writing a news article. True. /snip I agree, but you need a purpose for a release. Releasing just so it happens often is pointless. There should be a consistent amount of change/bug fixing/docs etc for a release to be made. Agreed. But thats not a release. Thats called lying to yourself/others that you have a release when you really just have a build. -Andy -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://www.multitask.com.au/developers -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Now what? (was: Jakarta Overview)
Subject: Re: Now what? (was: Jakarta Overview) From: Jon Carnes [EMAIL PROTECTED] === Andrew C. Oliver wrote: 'News' as a measure of activity on a project is effectively useless. Commits/month would be a lot better. True. /snip I agree, but you need a purpose for a release. Releasing just so it happens often is pointless. There should be a consistent amount of change/bug fixing/docs etc for a release to be made. Agreed. But thats not a release. Thats called lying to yourself/others that you have a release when you really just have a build. -Andy I believe that you have to have a release periodically (even if the changes are not dramatic). These things are cyclical. If you want to keep the focus of your community, you have to generate releases. Agreed that they should not be pointless, but I can't imagine a truely pointless release. We always have *some* progress. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Now what? (was: Jakarta Overview)
On Sat, 2002-03-23 at 21:25, Jakarta General Newsgroup wrote: Subject: Re: Now what? (was: Jakarta Overview) From: Jon Carnes [EMAIL PROTECTED] === Andrew C. Oliver wrote: 'News' as a measure of activity on a project is effectively useless. Commits/month would be a lot better. True. /snip I agree, but you need a purpose for a release. Releasing just so it happens often is pointless. There should be a consistent amount of change/bug fixing/docs etc for a release to be made. Agreed. But thats not a release. Thats called lying to yourself/others that you have a release when you really just have a build. -Andy I believe that you have to have a release periodically (even if the changes are not dramatic). These things are cyclical. If you want to keep the focus of your community, you have to generate releases. Agreed that they should not be pointless, but I can't imagine a truely pointless release. We always have *some* progress. I tend to differentiate between builds and releases -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Now what? (was: Jakarta Overview)
Dear Friends! First off, many thanks to Ted for posting my Draft Jakarta Overview, thus allowing everyone to review it, and many thanks to all who provided feedback on it, for or against. I would like to comment on some of the issues raised. - Purpose and Redundancy: To clarify the intended purpose of the document, it may help to explain how it came about: When I started to hang around the Jakarta website, my first desire was to get a good, high-level overview, so that I would then know where to dig deeper into those projects which are relevant to me. I followed every link on the main page to each individual project's homepage, and then on to the sub-projects where appropriate, compiling exactly the information in the submitted document. Took me several days. Assuming that others will have the same experience (and Chris' and Endre's emails seem to indicate they do), I decided to make it available.Just having all the information in one place can help a lot! (The overview on the Jakarta homepage, although great, does not contain either subprojects, or status information.) - Audience and Marketing: The document is directed towards people who may not be familiar with all the projects that exist under the Jakarta umbrella. Specifically, it is directed towards users, who hope to find something useful for their own projects. (Those users may turn into contributors over time!) I cannot understand why Leo and Ceki refer to the document (and, by implication, others like it) as Marketing - a term which carries in this context clearly condescending connotations. I don't think documentation is marketing - and what I tried to provide is simply documentation, not different in principle than Javadoc, only at a higher level. It is also simply not true, as Ceki believes, that everybody knows Jakarta: from the inside it may be hard to conceive how large and confusing the entire Jakarta project can appear to the outsider. - Users vs Developers I sense a certain ambivalence towards making Jakarta projects easier to use - Ted, for instance, points out that more users lead to more support questions (and mailing list discussions, such as this one). But isn't this stance slightly contradictory? If you don't want users, why publish your products? (By the way, I, as a user, am grateful that you do make them public - and that's why I am trying to support this project where I believe it needs it!) Just for balance, Endre puts usability first - I guess, it's a balancing act. - Hello, World and Javadoc: Danny suspects that I have a downer on Javadocs. That is not quite correct. I think Javadocs are great - as a reference. I think they are terrible for just finding out what a project is all about. Overview, Tutorial, Reference: three very different things! I would like to repeat my conviction that for first-time users (and all of us are at that stage at some point in our lives!) worked examples would be immensely helpful in understanding the scope and purpose of each project. It would be great if this could come either out of the projects themselves, or from the larger user community. It is great to see Andrew encourage contribution of documentation to individual projects. - Personal Assessment and Maintenance: Several people pointed out that the document contains subjective assessments. This may be true, and may have been unfortunate. I think a much better approach would be if the status ratings, for instance, came out of the projects themselves, along the lines of: 'alpha', 'beta', 'stable', or somesuch (and I would like to thank Andrew for suggesting that anybody unhappy patches it - and which is already happening!). In terms of maintenance: Once everything is set up, this should not take too much effort (just updates of revision numbers and release dates, really). I think I also hinted (cough) that I might be willing to help with that (to the degree that I have available resources, of course) provided that maintaining such an overview document at all is solidly supported by the community. - Commons Components: I am sorry, I have overlooked the Commons Components page, which provides the equivalent of what I tried to do (for the Commons project) - my mistake. I apologize. And thanks to Rodney for pointing it out. Now what? = It seems to me that overall a high-level Jakarta overview is being considered useful, or at least mostly harmless by most. The main contentious issues seems to be the perceived subjective assessments, which are already being patched out: by people closer to the projects and therefore more knowledgeable than me. That's great! The News section has also disappeared - I consider that a bit sad: I think some measure for the activity of the project would be helpful, but there may be better ways to determine it. I would have thought that the date of the most recent release would not be considered a subjective judgement. The question is: Now what? Should we: -
Re: Backing out...(was: Re: What is Jakarta?)
Jon Stevens [EMAIL PROTECTED] writes: [*] Anyway, my point being that I'm really getting tired of being misread, misunderstood and being considered the general pain in the ass around here. My being here isn't helpful for me and it certainly isn't helpful for the community. [elegy] So long and thanks for all the fish. You're not only a pain in the ass Jon, but an inconsistent pain in the ass. What's the point in saying goodbye and then keep on posting? -- Jan-Henrik Haukeland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Backing out...(was: Re: What is Jakarta?)
Jan-Henrik Haukeland wrote: So long and thanks for all the fish. You're not only a pain in the ass Jon, but an inconsistent pain in the ass. What's the point in saying goodbye and then keep on posting? I admit that I have a history of being obtuse, but the above sequence of words strikes me as particularly ironic. For those who care, http://www.sf.co.yu/science/hitchh4.htm . Meanwhile, I will readily agree that Jon is at times - OK, quite frequenty; oh, all right, pretty much all of the time - is a pain in the ass. But it is also important to realize that without him being exactly the way he is, this little community that we all are a part of quite possibly wouldn't be here. And Tomcat 3.3 probably wouldn't have a ratified release plan or nearly as many volunteers to support it. Nor would we be aware of the extent of the overlap between the various subprojects. Whether everyone here realizes it or not, we get a lot of benefit from Jon being here. It just is a shame that more people don't take the effort to return the favor sometimes. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Backing out...(was: Re: What is Jakarta?)
And Tomcat 3.3 probably wouldn't have a ratified release plan or nearly as many volunteers to support it. +1. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Backing out...(was: Re: What is Jakarta?)
on 2/11/01 7:31 AM, "Jan-Henrik Haukeland" [EMAIL PROTECTED] wrote: You're not only a pain in the ass Jon, but an inconsistent pain in the ass. What's the point in saying goodbye and then keep on posting? Go back and read my email again. What I said is that I was not going to take part in PMC level decisions. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ http://java.apache.org/turbine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Jakarta?
A little backstory on the connection pooling mechanism I submitted to Struts a while back: A couple of months ago, at the company I work for we ran into problems with the connection pooling implementation within the commercial product we were using. Specifically, (a) the pool itself was buggy and (b) the pool implementation made it difficult for us to pool PreparedStatements and the parse rate of unpooled PreparedStatements within the database was becoming a bottleneck to application performance. For this reason I put together a Connection/PreparedStatement pooling implementation that met our needs. Completely independently, I noticed the Struts project on jakarta.apache.org, started to poke around a bit, and subscribed to struts-dev and struts-user. I noticed that Struts had a basic connection pooling implementation. I also noticed several requests on struts-dev and struts-user looking to expand the functionality on the Struts connection pool. Many of the features (in fact all of the features) that were being asked for were/are features of the Connection/PreparedStatement pool I put together. So, I repackaged my code as org.apache.struts.*, and submitted it to the list. This is the way open source development is supposed to work, no? I had an itch, I scratched it. I noticed others had the same itch, so I offered it up. Now, unbeknownst to me, the Turbine project over at java.apache.org also has a connection pooling library with similar functionality. Maybe it's my fault for not knowing this. Maybe it's the struts-dev folks fault (sorry guys) for failing to mention that there is a connection pooling library in Turbine over at java.apache.org. Maybe it's Apache's fault for not providing a clear picture of what is available and where. Maybe it doesn't matter anyway because I think my pool is better designed, easier to maintain, or more feature rich than the existing one, in which case I think it's up to the community to decide which implementation they'd like to use. (And before we go off on a a holy war here, I'm not saying that I do think that. I'm specifically not saying that one impl is better or worse than the other. Not having looked at the Turbine stuff in detail, I'm in no position to state that. I'm just saying that that is a valid position to take. It could be wrong (in the eyes of the community) but it's not unreasonable.) Jon's response to this, when brought up in a slightly different context, was a bit off-putting: Meanwhile, I do think there would be a lot of interest in a Jakarta connection pool. In fact, someone has offered to donate one to Struts. http://marc.theaimsgroup.com/?l=struts-devm=97967619230491 Totally friggen lame. *All* of that code (and more) is already implemented in Turbine and can be used outside of the core "Turbine" system very easily. If all of that functionality is available in Turbine, that makes it *redundant*, not lame. Moreover, having poked around a bit in the Turbine stuff (and granted, I didn't poke that hard or that long, so maybe I missed it), it seems to me that not "all of that code is already implemented in Turbine". Specifically, (a) I don't see that Turbine is doing any pooling of PreparedStatements, which if you recall was the major itch I was trying to scratch, (b) Turbine's Connection pool seems to require specific references to TurbineDB--so that legacy code has to be retrofitted to work with Turbine's pool, (c) Turbine's pool doesn't seem to support a javax.sql.DataSource interface. Could Turbine's pool be modify to support these things? Of course, but I wasn't aware of Turbine's pool when I first submitted mine. Moreover, Jon's response doesn't make me feel like my contribution is very welcome there. Frankly, there seems to be some underlying Turbine vs. Struts politics here that I don't want to get involved in. If you'd like to debate the merits of one pooling implementation versus another, or to work to see the full suite of functionality implemented in a single pooling library, or perhaps to debate whether or not more than one pool implementation is warranted, then let's do so. But I don't think a knee-jerk response like that does much more than alienate potential developers. I was going to segue this into a discussion of how a more modular utility/services/library project or set of projects is warranted, but I see that Morgan and Ted have already kicked that off in earnest, so I'll follow up in that thread. - Rod -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 4:23 PM To: '[EMAIL PROTECTED]' Subject: RE: What is Jakarta? It may not be easier, but it's certainly more fun. And it often seems easier to build to suit than to adapt something. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 3:24 PM To: [EMAIL PR
RE: What is Jakarta?
Thursday, February 08, 2001 10:29 AM GOMEZ Henri wrote: I'm +1 with Arieh Markel about . Jakarta Base Network Utilities . Jakarta Base JSP Utilities . Jakarta XML Utilities . Jakarta SMTP Utilities . Jakarta Tools How do you make the tools so that they don't tie into applications too closely, or become sub-applications - not needed to build any Jakarta project. Or can they if they are still add on tools for a Jakarta package. Theo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What is Jakarta?
Costin Manolache wrote: What's wrong with having multiple thread pools or db pools, each having special characteristics and working best in different situations ? Different, plug compatible, db pools would be great. Having each project early bind to a specific one is not. If I wanted to run JetSpeed and Coocoon today on the same web server, I would have to statically apportion my database connections between the two. Add Struts into the mix and I must further subdivide. Overall, I'm not overly concerned if we have multiple XML mappers. Arguably it would be better if we didn't, but on the other hand a little duplication sometimes removes the requirement for a lot of coordination. In other words, if this is an itch that somebody wants to scratch, I would encourage them to do so, but if not, I wouldn't want to mandate it from above. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is Jakarta?
Since Java-Apache has apparently never actually been charted by the ASF, why not ask the board go ahead and charter it like the recent PMCs for PHP, Perl, and TCL, e.g. " ... the Apache Java Committee be and hereby is responsible for the creation and maintenance of software related to the Java programming language ... but excluding Java Servlet-related software which is the responsibility of the Apache Jakarta Committee;" This could lead to something like : java.apache.org Alexandria - a CVS/Javadoc/Source code/Documentation management system. Ant - a Java based build tool. CJAN - [early planning stage - method for distributing Java components] JMeter - a desktop application load test functional behavior and measure performance. Logj4 - a tool to help the programmer output log statements to a variety of output targets. ORO - a set of text-processing Java classes that provide Perl5 compatible regular expressions. RegEx - a regular expression package for Java. jakarta.apache.org JServ - a servlet engine implementating the Java Servlet 2.0 API. JSSI - a Java servlet that implements the SERVLET tag as specified by the Java Web Server. Tomcat - the Reference Implementation for the Java Servlet 2.2 and JavaServer Pages 1.1 APIs. Watchdog - validation tests for the Servlet and JavaServer Pages specifications Avalon - a common framework for server applications JAMES - an enterprise mail server (Java Apache Mail Enterprise Server). Jetspeed - an enterprise information portal. Slide - a WebDAV content management system. Jyve - a servlet-based FAQ-O-Matic system. ECS - the Element Construction Set generates elements for various markup languages. Struts - a Model 2 (MVC) application framework. Taglib - a JSP taglib repository. Turbine - a servlet-based framework for experienced Java developers. Velocity - a template engine providing an alternative to Java Server Pages (JSPs) or PHP. / This addresses Jakarta being "out of scope", and mitigates the question of whether a single PMC can oversee so many subprojects. The new Apache Java PMC (consisting of active committers from those subprojects) can then focus on the best way to organize and expose the smaller toolsets, which may also be useful to the XML products. Also, was the following ever discussed at the members meeting, and if so, what was the outcome? 1) should the PMC report directly to the board 2) should the PMC consist entirely of ASF members 3) should the PMC chairperson be an ASF member 4) should the PMC composition be set by the board or delegated to the project after the initial PMC creation 5) should the appointment of the PMC chairperson be restricted to candidates proposed by the project I'm about to make another pass at the proposed guidelines, and want to be sure we are in compliance with any recent resolutions. I've read the ASF board minutes, but haven't found the "member" minutes. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 425-0252; Fax 716 223-2506. -- http://www.husted.com/about/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What is Jakarta?
--- Ted Husted [EMAIL PROTECTED] wrote: On 2/6/2001 at 11:26 AM Delagrange, Morgan wrote: Right, but the Jakarta PMC chairman objects to that definition. I'm not sure if Sam Ruby has actually "objected" or not. It is evident that Roy Fielding has objected to the scope of the Jakarta Project. As it stands, the current mission given on the Web site is technically incorrect. If we want a broader scope, it's obvious that the ASF will require a board resolution to put things right. From Sam's comments, it seems pretty clear that he'd rather expand the scope than start pruning subprojects. If you make the definition of Jakarta this restrictive Jakarta's charter is * already * that restricted. The contract between the ASF and the Jakarta PMC reads that Jakarta is "charged with the creation and maintenance of open-source Java Servlet-related software for distribution at no charge to the public." Agreed, many Jakarta projects are currently out of scope according to the current charter. As you pointed out, the Jakarta PMC has exceed its original charter. The ASF board chairman has raised an exception, and presented two alternatives: (1) A broader charter or (2) More PMCs. Some people seem to like the idea of a broader charter. Other people have said they don't. I'm just suggesting that as a followup to Roy's suggestion (2) that we consider whether chartering Java-Apache for the out-of-scope projects makes any sense. Thanks to Jon for clarifying the deprecation of the java.apache.org domain. The current Jakarta site states: The older Java Apache Project will have its projects merged into the Jakarta Project in the near future (no set date). For more information please see the announcement on that website. If this is still the case, fine. If not, we need a new plan of action, since clearly java.apache.org needs to go away. Really, if you limit the scope of the Jakarta project to Servlet-based technologies, the list of in-scope projects is very short: But, is that a bad thing? It's too specific. See next comment. projects like Slide and Struts, which only deal with servlets in part I can't vouch for Slide, but Struts is definately Java Servlet-related software. I didn't say there weren't servlet-related components in Struts, I'm saying there's a lot more in Struts than servlet stuff; hence you can easily argue that Struts is not entirely in-scope. Much of Struts deals with servlets, but Struts also provides frameworks for XML parsing and database pooling, correct? Since these are not specifically servlet-related, they would have to be removed from the project. I'm not arguing for Jakarta becoming the one giant Java project, I'm just saying that a Servlet-oriented charter is too inflexible. I'd rather see a charter that focuses on Java servers and related tools (and I think Ant in particular may not fit, but that's another argument). - Morgan = Morgan Delagrange Britannica.com __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What is Jakarta?
At 16:01 06.02.2001 -0500, you wrote: On 2/6/2001 at 9:13 PM Ceki Glc wrote: What would be gained by refining the charter of Jakarta and pruning projects? Roy Fielding has indicated that some action is necessary. His two suggestions were to either ask the board to create additional PMCs, or to broaden the scope of the existing PMC. What decisions does the PMC take? Part of the problem is that the ASF PMC's are a recent invention, so no one is entirely sure how they should work We are working on that as part of the update to the guidelines at http://jakarta.apache.org/site/proposal.html#management . Thanks for the link. Here is an excerpt from that document: Responsibilities of the PMC include: - the active discussion of Project issues, strategic direction, and forward progress, - the consideration and approval of new subprojects, - retiring inactive subprojects and Committers as necessary, - arbitrating otherwise intractable disputes regarding subproject voting and vetos, - the security and reliability of the Project's Web site, mailing lists, code repositories, and related services, - legal issues involving the Project and its subprojects, and maintaining Project and subproject scope as chartered by the ASF corporation As I understand it, the main responsibility of the PMC is to decide whether to include a sub-project under the Jakarta label and possibly act as an arbitrator in case of conflicts within a sub-project. There is also the task of managing the Jakarta web-site + mailing lists but that is probably less strategic a task (read: a chore). :) My guess is that when all strictly sub-project related tasks are delegated to the committers, the PMC could fulfill its role even in the presence of many, say 10 to 20 sub-projects. Am I missing anything obvious? Cheers, Ceki Ceki Glc e-mail: [EMAIL PROTECTED] (preferred) av. de Rumine 5 [EMAIL PROTECTED] CH-1005 Lausanne SwitzerlandTel: ++41 21 351 23 15 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Jakarta?
on 2/6/01 5:04 PM, "Ted Husted" [EMAIL PROTECTED] wrote: I still don't quite get why this is such an issue. The efficiency of a pool comes from sharing connections that use the same login to the same database. It would be likely that Jetspeed, Turbine, and Struts may all want to connect to the same DBMS, but they would not usually want to connect to the same database using the same login. However, what is missing (from everything BUT Turbine's implementation) is a "Service" that would allow you to have multiple database connection pools to multiple different backends with different login account settings. This *is* something that Turbine provides. Eventually, someone will come along to the Struts project who needs this functionality and it will get re-implemented yet again. Meanwhile, I do think there would be a lot of interest in a Jakarta connection pool. In fact, someone has offered to donate one to Struts. http://marc.theaimsgroup.com/?l=struts-devm=97967619230491 Totally friggen lame. *All* of that code (and more) is already implemented in Turbine and can be used outside of the core "Turbine" system very easily. Perhaps the thing to do would be to circulate a Request for Proposal to the subprojects that might use database connections, and see what we get back. No, the right direction would be to use the project which implemented this code first and has the most complete solution and ask that project to externalize their code in such a way that it could be used in other projects. Oh wait. The Turbine Project already did all of that work. It really disappoints me that Craig and the Struts project have completely ignored the fact that they said he wouldn't compete with Turbine and would instead work with us instead of re-implementing everything...instead, now we have a war of duplication between Turbine and Struts. As a result, I'm now creating an Essay titled "You make the decision." that will explain in detail the differences on implementing a system based on top of Struts+JSP and Turbine+Velocity. It will be up to our user base to choose the one they prefer and the amount of lower level duplication will continue to grow until someone wakes up and realizes that this code can be generalized into another project... But, I'm not going to start working on that other project until I can get agreement and proof that Struts community will contribute to the project because so far, they have refused to contribute to Turbine which is the project they are duplicating... Sigh. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ | http://java.apache.org/turbine/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
