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]
FW: RE: RE: Jakarta Overview
-Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] -- I see a need for more integration documentation and top-down documentation. Jakarta isnt heirarchical, at all, and is in fact grossly federal, with member projects able to petition to join, cecede, be expelled. There are few federal laws, but many local ones which vary from project to project, and federal government in the form of the PMC does not represent all the interests of each project, or impose homogenaity(or whatever the word is!). Therefore federal documentation should limit itself to providing a map of the member projects, and the location their own documnetation. d. -- 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 assessments
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: FW: RE: RE: Jakarta Overview
I should draw you a diagram of new federalism it would wreck your mind... ;-) On Sat, 2002-03-23 at 05:07, Danny Angus wrote: -Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] -- I see a need for more integration documentation and top-down documentation. Jakarta isnt heirarchical, at all, and is in fact grossly federal, with member projects able to petition to join, cecede, be expelled. There are few federal laws, but many local ones which vary from project to project, and federal government in the form of the PMC does not represent all the interests of each project, or impose homogenaity(or whatever the word is!). Therefore federal documentation should limit itself to providing a map of the member projects, and the location their own documnetation. d. -- 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]
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]
Re: Jakarta Overview
On Wed, 20 Mar 2002, Waldhoff, Rodney wrote: | Well said Andrew. | | Re. Chris's point, I think we'll be hard pressed to reach consensus on what | a project maturity means, let alone how to measure it. | | If I were building this document (and if I remember correctly, I built this | document: http://jakarta.apache.org/commons/components.html, which is rather | similiar in some respects), I'd stick to factual information--brief | description, release dates/numbers, etc. and let the facts speak for | themselves. As those numbers are pretty different from project to project, I think that's not very indicative (?). # downloads is _interesting_, but of course it doesn't say very much. But it _is_ interesting and does actually say something about the combination of usability (audience) * maturity. Regarding Ted's comments about large user base being bad: that's just to weird. A large user base WILL make a product better. The worst thing that can happen to a product is that the developers sits inside their tech-box and just develops cool shit. The _usability_ of the product must always be in front. And there you have the users. And the users of these products most often being developers themselves will give the product more development, guaranteed. There _are_ itches that's just so annoying that even I will try to fix them... -- Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
On Wed, 20 Mar 2002, Ceki Gülcü wrote: | | Isn't the overview document trying to substitute itself for the | documentation that is already in subprojects (or should be)? No. It's an overview of what's inside of jakarta. Great! | The cornerstone of the Jakarta and Apache Software Foundation in | general is that management delegates responsibility for a given | subproject to each subproject, intervening as little as possible. | | Your introduction also raises further worries. Jakarta does not need | more publicity. Everybody knows Jakarta. What is needed is improving | the quality of each *subproject*. Marketing gimmicks are not helpful and just | waste precious time. I don't agree. I still haven't browsed around all those projects and subprojects. I think this idea is great. Give me a two-line lowdown of what the stuff is, so that I can decide whether it is worth clicking on for my own part. Jakarta's cryptic names doesn't exactly say much, do they? | | More importantly, who is to decide what project has what maturity? I find | the overview document a little too interventionist, perhaps less in content | than in sprit. Until these concerns are addressed, here is my -1. Why not put it in the public and see what happens?? [btw: WHY don't people cut away the shit they don't reply to?? It's SO annoying.. ] -- Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Give me a two-line lowdown of what the stuff is, so that I can decide whether it is worth clicking on for my own part. Jakarta's cryptic names doesn't exactly say much, do they? Try and look at the front page for, admittedly a one liner, but one without subjective overtones, which doesn't present a non-contributors view of many projects as the Jakarta Overview Definition of what the project is. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Danny Angus wrote: Try and look at the front page for, admittedly a one liner, but one without subjective overtones, which doesn't present a non-contributors view of many projects as the Jakarta Overview Definition of what the project is. The overview has been donated to the ASF, and is under Jakarta rules now. If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. We are very quick to say Thanks for Volunteering around here. OK, someone volunteered, and we got what we wished for. Apache stands for patching ... -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
The overview has been donated to the ASF, and is under Jakarta rules now. If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. We are very quick to say Thanks for Volunteering around here. OK, someone volunteered, and we got what we wished for. Apache stands for patching ... Well said friend, I totally agree! -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- 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]
RE: Jakarta Overview
Ted, I don't want to have an argument, and I'm not criticising Philipp for offering, nor for the effort he obviously put in. I do have some reservations with this particular page, which I'm not going to raise again, if anyones interested they've already read them. I would like to take you up on a couple of points you make though, The overview has been donated to the ASF, and is under Jakarta rules now. Does this mean that anything donated is accepted on behalf of the project, by anyone with karma, without discussion and can therefore only be openly opposed once it has already been accepted? If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. What if (and I don't, I'm just asking) modification and inaction are not enough for me, I want to veto it? I don't have enough Karma for Jakarta-site2, but if I did would I be within my rights to arbitrarily remove it? I think, and hope, not. Therefore it seems that it is a bigger hurdle for a donation of this kind to be vetoed than accepted. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. You're absolutely right, I agree utterly with that statement, and I hope my miserable grumping doesn't put him off. Apache stands for patching ... But we don't want to have to patch any old thing that comes swinging by, do we? Surely there could be a slightly better, and simple, way of accepting website proposals that makes it obvious that they are undergoing peer review? And in the interests of providing construtive criticism I'll propose -- A proposals section of the site, into which anyone with karma can commit any submissions and from which documents can be promoted by lazy concensus of all jakarta commiters. Its stylesheet will include a footer explaining the status of proposal documents(if thats possible). -- for instance? d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
I'm not Ted, but let me take a stab. :) - Original Message - From: Danny Angus [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Sent: Friday, March 22, 2002 7:09 AM Subject: RE: Jakarta Overview Ted, I don't want to have an argument, and I'm not criticising Philipp for offering, nor for the effort he obviously put in. I do have some reservations with this particular page, which I'm not going to raise again, if anyones interested they've already read them. I would like to take you up on a couple of points you make though, The overview has been donated to the ASF, and is under Jakarta rules now. Does this mean that anything donated is accepted on behalf of the project, by anyone with karma, without discussion and can therefore only be openly opposed once it has already been accepted? Yes, that is the Commit Then Review philosophy. You cannot prevent anyone from initially committing anything, but one it has been committed you can vote it down. If anyone wants to make it more objective, have at it. If not, leave it alone and it will wither away. What if (and I don't, I'm just asking) modification and inaction are not enough for me, I want to veto it? I don't have enough Karma for Jakarta-site2, but if I did would I be within my rights to arbitrarily remove it? I think, and hope, not. Therefore it seems that it is a bigger hurdle for a donation of this kind to be vetoed than accepted. You cannot arbitrarily remove it, but you can veto it. Under the current, slightly strange, default voting rules for Jakarta, Ted would have to talk you out of your objection; if he could not, he might have to back out his change (or you could do it for him). Any changes to a product require consensus approval. Does the website fit under the definition of a Jakarta product? A good question, which does not come up very often. Usually committers are more permissive of website changes then code changes. Regardless of the content, it's important to recognize that the initial author Did The Right Thing. The overview was prepared in XML and required no afterwork to commit. This makes him a Contributor in my book. If more of our users went to the trouble this person went to, we'd have more and better documentation throughout Jakarta. You're absolutely right, I agree utterly with that statement, and I hope my miserable grumping doesn't put him off. Apache stands for patching ... But we don't want to have to patch any old thing that comes swinging by, do we? Surely there could be a slightly better, and simple, way of accepting website proposals that makes it obvious that they are undergoing peer review? Well you can always exercise your veto. Then the committer backs it out, discusses changes on the list, makes some modifications, and resubmits for another vote. And in the interests of providing construtive criticism I'll propose -- A proposals section of the site, into which anyone with karma can commit any submissions and from which documents can be promoted by lazy concensus of all jakarta commiters. Its stylesheet will include a footer explaining the status of proposal documents(if thats possible). -- for instance? d. We have that section. It's called CVS. :) It operates exactly the way you describe. - Morgan _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
On Friday, March 22, 2002, at 01:09 PM, Danny Angus wrote: snip And in the interests of providing construtive criticism I'll propose -- A proposals section of the site, into which anyone with karma can commit any submissions and from which documents can be promoted by lazy concensus of all jakarta commiters. Its stylesheet will include a footer explaining the status of proposal documents(if thats possible). -- for instance? without wanting to sink the idea (even though it might), it's not clear how lazy consensus works (even at the moment) as far as the site goes. is it everyone with jakarta-site karma, is it all committers or is it just the PMC? the voting processing for the site would need to be clarified before we could even think about creating a system that uses that it. conversely if we find that we aren't able to get the community momentum required to clarify the process then the system will be built on sand. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Hi, I'll try not to keep banging on about this, I know its not that important in the great scheme of Why We Are Here :-) but .. Yes, that is the Commit Then Review philosophy. You cannot prevent anyone from initially committing anything, but one it has been committed you can vote it down. Ok, thats fair enough. Any changes to a product require consensus approval. Does the website fit under the definition of a Jakarta product? A good question, which does not come up very often. Usually committers are more permissive of website changes then code changes. The issue for me is that the website is in a perpetual state of releasing the head of cvs every time a change is made, there is no un-released development state for the website, and while there is arguably a conceptual pre-release state while things are being reviewed it isn't clear to people who don't know our ways that some documents may carry the full weight of approval, or be Rules, or Codes of Conduct, yet others, undifferentiated, are merely proposals and possibly contentious at that. [The PMC should, of course, have unfettered right to publish. Its part of their role.] We have that section. It's called CVS. :) It operates exactly the way you describe. Not if the head is going to be built and released everytime someone commits something new. and if it isnt then its harder for people to review new material. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Morgan, Your point about trust is well made, I think that its is the straw I was grasping for! I seem to have temporarily overlooked the fact that this whole edifice is glued together by trust already, and to not have a more explicit mechanism regarding the website made me neglect that.. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: RE: Jakarta Overview
Andy, Another good point, I do seem to have taken a robustly negative view of all this. Perhaps too much so. d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
- there's too many committers in jakarta to get 'em all to vote on jakarta-site2. Pointless waste of energy, imho. - committers are responsible people (or they should be, at least!) - as a whole, open source lacks docs. So does Jakarta. For those that disagree: look at sensible-documentation-per- api-method at msdn.microsoft.com, then look at us. - many people monitor the site and its changes. The points above lead me to believe the current (lack of rigid) system is the right one. And I do think we all agree that the jakarta site should be as objective as possible. regards, - Leo Simons -- 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: Jakarta Overview
I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: Greetings! I have been following some of the recent discussions on this mailing list about possible directions for the Jakarta project. I would like to offer the following observation: To have code and projects coming out of Jakarta being more widely adopted, developers first need to be aware of them, then they have to be able to judge whether a Jakarta project is suitable for the developers' needs. I believe that the Jakarta website could do more to make its products easily accessible. It is often not easy to tell what a project is actually about, what the project's scope is, how its functionality is achieved, or how mature and usable the existing code base is. Evaluating an of-the-shelf component usually is an iterative process: In a first step one tries to determine the overall purpose of the component, and whether it is suitable for one's purpose at all. In later steps, one may consider how the component works, and what distinguishes it from comparable/competing products. The Jakarta subprojects support this evaluation and decision process to various degrees. The one that I am most familiar with (Velocity) is exceptional in this regard (mere coincidence?). But some (sub-)projects force the potential user to study the Javadoc to find out which problem the project attempts to solve, which is probably unacceptable for many visitors. I think it would be helpful for everyone (in particular in light of the desire to see Jakarta code being more widely adopted in outside projects) to try to improve the information offered here, and to support visitors in their evaluation and decision process as much as possible. After this introduction... Here is what I have done: I have scoured the entire Jakarta website and compiled information not only on each project, but also on each of the subprojects (such as those in the Commons, or those that are part of Avalon or Turbine), which are not immediately visible when visiting the Jakarta homepage. For each project, I have included a short, one-paragraph description (often taken from the projects webpage), but I also tried to give a sense of the maturity and the activity of the project. For anybody wanting to use (as opposed to develop) Jakarta code in their own projects, this information will play a significant part in their final decision. (I report the version number as proxy for the maturity and the extend of the News section of each project as proxy for its activity.) I hope that by providing the information not only about the top level project, but also about all the individual subprojects in one location, a visitor to the site will have an easier time assessing purpose and scope of each of the projects. I would hope that this can be extended in the future to include the following: - a concise abstract, stating what the project is about and what purpose it serves (the foundation for which I hope to provide here, based on what many projects already offer on their individual homepages) - a description how the project works, possibly by walking the visitor through a Hello, world example
RE: Jakarta Overview
Perhaps you could become a Jakarta developer by altering the provided overview so that it is both useful to users and acceptable to the developers of the projects it covers. I should say a subjective (mature/immature/good/bad) information might be useful, but probably is more the area of a Jakarta fan-site ;-) then the Jakarta site itself. Furthermore, just a personal opinion, Documentation is an area I truly want to help improve at Jakarta as a whole. But, one thing I've noticed is that it is much easier to contribute documentation at the project level and work your way up then vice versa. I like the overview myself, its a clear and gives folks an easier way to find what they need. I yet understand the concerns about keeping it up to date and the likes. My suggestion is though is too fold. General tends to give new contributers who read the literature about community and the likes a trial by incident, a series of -1 no I don't like it! and depend upon the contributer to climb the mountain. Rough for a first timer. Perhaps trying to be a bit more positive and saying good but have you considered instead of the more traditional approach. ;-) Secondly, to the contributer of said documentation and future contributers. While end to end documentation is seriously lacking, I suggest contributing to the in developing Jakarta Manual and furthermore the lower level project documentation first. Try not to include too much subjective information (cause for debate) and don't take it personally ;-) or anything anywhere at anytime too seriously. (air raids and the likes excluded) -Andy On Wed, 2002-03-20 at 05:35, Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: Greetings! I have been following some of the recent discussions on this mailing list about possible directions for the Jakarta project. I would like to offer the following observation: To have code and projects coming out of Jakarta being more widely adopted, developers first need to be aware of them, then they have to be able to judge whether a Jakarta project is suitable for the developers' needs. I believe that the Jakarta website could do more to make its products easily accessible. It is often not easy to tell what a project is actually about, what the project's scope is, how its functionality is achieved, or how mature and usable the existing code base is. Evaluating an of-the-shelf component usually is an iterative process: In a first step one tries to determine the overall purpose of the component, and whether it is suitable for one's purpose at all. In later steps, one may consider how the component works, and what distinguishes it from comparable/competing products. The Jakarta subprojects support this evaluation and decision process to various degrees. The one that I am most familiar with (Velocity) is exceptional in this regard (mere coincidence?). But some (sub-)projects force the potential user to study the Javadoc to find out which problem the project attempts to solve, which is probably unacceptable for many
Re: Jakarta Overview
Jakarta is developer-centric because developers are the ones who volunteer to do the work. They need working products to use with their paying jobs, and find that sharing the development load works better than going it alone. We don't get many marketing volunteers because there is very little payback. More marketing generates more users, but that doesn't always translate into more development or better products. Sometimes more users can actually hurt development, since user support distracts developers from developing. (Only so many cycles in a day.) I do a lot of work on product documentation myself, mostly becuase I have a mind like a sieve, and need it for my own reference. But for most developers and users, there is less of a payback, since once they know the product they don't feel the need to document it for their own use. Jakarta is here to build products. If someone wants to market those products, that's great. If volunteers want to provide commit-ready documentation, like Phillip did, I'll fulfill my responsibility as a committer, and post it. But the problem now is, who's going to maintain it over the long run? If the developers want to, that's great, but if they don't, well, how the other committers spend their volunteer hours is up to them. So, sure, some clear exposition about Jakarta would help a lot of people. If someone has an itch for more documentation, they should create it and share it with the group in a ready-to-commit format, as Phillip did. Though, I'm sure anyone ready to do the work doesn't need someone else to suggest the idea. Jakarta cannot be anything by design; it can only be what the volunteers make it. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Web: http://husted.com/struts Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
Well said Andrew. Re. Chris's point, I think we'll be hard pressed to reach consensus on what a project maturity means, let alone how to measure it. If I were building this document (and if I remember correctly, I built this document: http://jakarta.apache.org/commons/components.html, which is rather similiar in some respects), I'd stick to factual information--brief description, release dates/numbers, etc. and let the facts speak for themselves. -Original Message- From: Andrew C. Oliver To: Jakarta General List Sent: 3/20/2002 6:27 AM Subject: RE: Jakarta Overview Perhaps you could become a Jakarta developer by altering the provided overview so that it is both useful to users and acceptable to the developers of the projects it covers. I should say a subjective (mature/immature/good/bad) information might be useful, but probably is more the area of a Jakarta fan-site ;-) then the Jakarta site itself. Furthermore, just a personal opinion, Documentation is an area I truly want to help improve at Jakarta as a whole. But, one thing I've noticed is that it is much easier to contribute documentation at the project level and work your way up then vice versa. I like the overview myself, its a clear and gives folks an easier way to find what they need. I yet understand the concerns about keeping it up to date and the likes. My suggestion is though is too fold. General tends to give new contributers who read the literature about community and the likes a trial by incident, a series of -1 no I don't like it! and depend upon the contributer to climb the mountain. Rough for a first timer. Perhaps trying to be a bit more positive and saying good but have you considered instead of the more traditional approach. ;-) Secondly, to the contributer of said documentation and future contributers. While end to end documentation is seriously lacking, I suggest contributing to the in developing Jakarta Manual and furthermore the lower level project documentation first. Try not to include too much subjective information (cause for debate) and don't take it personally ;-) or anything anywhere at anytime too seriously. (air raids and the likes excluded) -Andy On Wed, 2002-03-20 at 05:35, Chris Pheby wrote: I have to disagree! Speaking as a /user/ it is really hard to find projects on Jakarta, and how the various projects relate to each other. I have spent many weeks doing this and still haven't even scraped the iceberg. Which I think is a shame. Some clear exposition would really help. I have heard on this list that the Jakarta project is developer centric, and the site is hard to penetrate if you are not a Jakarta developer. I am sure this is not by design, but that is my perception as well. Any suggestion that helps improve this situation such as Philipp's I would hope has serious consideration - even if it presents new challenges that need to be resolved. As to deciding such things as how to assess the maturity of the project, how about taking measures such as: a) polls/votes of users b) number of downloads c) release number I'm sure there are other possibilities... Chris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ceki Gulcu Sent: 20 March 2002 10:27 To: Jakarta General List Subject: Re: Jakarta Overview Isn't the overview document trying to substitute itself for the documentation that is already in subprojects (or should be)? The cornerstone of the Jakarta and Apache Software Foundation in general is that management delegates responsibility for a given subproject to each subproject, intervening as little as possible. Your introduction also raises further worries. Jakarta does not need more publicity. Everybody knows Jakarta. What is needed is improving the quality of each *subproject*. Marketing gimmicks are not helpful and just waste precious time. More importantly, who is to decide what project has what maturity? I find the overview document a little too interventionist, perhaps less in content than in sprit. Until these concerns are addressed, here is my -1. At 16:36 18.03.2002 -0800, you wrote: snip snip
Re: Jakarta Overview
Waldhoff, Rodney [EMAIL PROTECTED] writes: Re. Chris's point, I think we'll be hard pressed to reach consensus on what a project maturity means, let alone how to measure it. If I were building this document (and if I remember correctly, I built this document: http://jakarta.apache.org/commons/components.html, which is rather similiar in some respects), I'd stick to factual information--brief description, release dates/numbers, etc. and let the facts speak for themselves. +1 -- sticking to the facts leaves the evaluation of a package up to the consumer. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jakarta Overview
Greetings! I have been following some of the recent discussions on this mailing list about possible directions for the Jakarta project. I would like to offer the following observation: To have code and projects coming out of Jakarta being more widely adopted, developers first need to be aware of them, then they have to be able to judge whether a Jakarta project is suitable for the developers' needs. I believe that the Jakarta website could do more to make its products easily accessible. It is often not easy to tell what a project is actually about, what the project's scope is, how its functionality is achieved, or how mature and usable the existing code base is. Evaluating an of-the-shelf component usually is an iterative process: In a first step one tries to determine the overall purpose of the component, and whether it is suitable for one's purpose at all. In later steps, one may consider how the component works, and what distinguishes it from comparable/competing products. The Jakarta subprojects support this evaluation and decision process to various degrees. The one that I am most familiar with (Velocity) is exceptional in this regard (mere coincidence?). But some (sub-)projects force the potential user to study the Javadoc to find out which problem the project attempts to solve, which is probably unacceptable for many visitors. I think it would be helpful for everyone (in particular in light of the desire to see Jakarta code being more widely adopted in outside projects) to try to improve the information offered here, and to support visitors in their evaluation and decision process as much as possible. After this introduction... Here is what I have done: I have scoured the entire Jakarta website and compiled information not only on each project, but also on each of the subprojects (such as those in the Commons, or those that are part of Avalon or Turbine), which are not immediately visible when visiting the Jakarta homepage. For each project, I have included a short, one-paragraph description (often taken from the projects webpage), but I also tried to give a sense of the maturity and the activity of the project. For anybody wanting to use (as opposed to develop) Jakarta code in their own projects, this information will play a significant part in their final decision. (I report the version number as proxy for the maturity and the extend of the News section of each project as proxy for its activity.) I hope that by providing the information not only about the top level project, but also about all the individual subprojects in one location, a visitor to the site will have an easier time assessing purpose and scope of each of the projects. I would hope that this can be extended in the future to include the following: - a concise abstract, stating what the project is about and what purpose it serves (the foundation for which I hope to provide here, based on what many projects already offer on their individual homepages) - a description how the project works, possibly by walking the visitor through a Hello, world example application. (Some Jakarta projects are exemplary in this, others are not. In particular for the larger projects, such as Avalon, Turbine, Struts, Jetspeed it is not easy to find out how to use them in one's own work and what benefits would be derived. Very extensive study is needed to find out whether the project would even be applicable.) - a comparison with comparable projects (Velocity is exemplary in that). I am not deeply familiar with many of the Jakarta projects (in particular, I can't quite fathom the full extend of some of the frameworks, such as Avalon or Turbine, at this time), but in the spirit of 'release-early/release-often' I would like to make the information I have compiled so far available to the community. Any feedback (if polite) is welcome, in particular corrections from people more knowledgeable about a given project. I will try to incorporate anything useful and feed it back into the community. As time goes on, I will try to fill in other pieces as well (such as worked examples) - any help or advice is welcome, of course! The compilation follows below - I have tried to encode it using the jakarta-site XML tags. My apologies if I am not using them properly. I think it would be wonderful if the document could be made available on the Jakarta website for review (unfortunately, I don't maintain a personal website at the moment). Best regards, Ph. Janert - Philipp K. Janert, Ph.D. janert at ieee dot org # Document begins below # ?xml version=1.0? document properties author email=janert at ieee dot orgPhilipp K. Janert/author titleJakarta Overview/title /properties meta name=keyword content=jakarta, java/ body section name=Libraries, Tools, and APIs
Re: Jakarta Overview
http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Nice docs, care to explain some things: Philipp K. Janert [EMAIL PROTECTED] wrote on 19/03/2002 11:36:35 AM: [snip] significant part in their final decision. (I report the version number as proxy for the maturity and the extend of the News section of each project as proxy for its activity.) [snip] I know for the stuff I do, 'News' is the least correct indicator of activity on a project. Much can happen on a project that developers don't find 'newsworthy', e.g. documentation. [snip] libDocumentation:nbsp;/bOverview, Javadoc, and XML syntax reference, documentation appears somewhat immature/li [snip] Can you clear up how the documentation appears somewhat immature for Latka? [snip] -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://www.multitask.com.au/developers
RE: Jakarta Overview
In order to avoid duplicate edits, can we just point the Commons section of this document to: http://jakarta.apache.org/commons/components.html -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 4:49 AM To: Jakarta General List Subject: Re: Jakarta Overview http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Overview
The concept of this document is perhaps a good one, but can you clarify how its role is distinct from the Jakarta Subprojects section of the homepage? Also, I take a bit of exception to the Documentation: None classification on commons-pool and commons-dbcp. The documentation is minimal, no doubt, and likely insufficient, but none suggests there's no need to keep looking for it, while if you do, you'll find fairly extensive JavaDocs: * http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/ind ex.html * http://nagoya.apache.org/gump/javadoc/jakarta-commons/dbcp/dist/docs/api/ind ex.html as well as some additional documentation for each: * http://cvs.apache.org/viewcvs/jakarta-commons/dbcp/doc/ * http://cvs.apache.org/viewcvs/jakarta-commons/pool/xdocs/ And I'll reiterate dion's comment: Documentation: Overview, Javadoc, and XML syntax reference, That seems pretty exhaustive for what Latka does.
RE: Jakarta Overview
Hi all, It feels like Philipp has a downer on javadocs, perhaps he should contribute docs to those projects he feels are inadequate rather than just criticising, how many offers of documention contributions do the various projects receive compared to actual submissions? It also reads as a pretty personal opinion of whats here, it would surely be better placed on a site which comments/observes/criticizes jakarta than the jakarta site? And anyway .. this information is all here already, the projects all maintain their descriptions worded as the contributors choose, I think project descriptions belong on their homepages, with the brief description on the homepage which I think seems fine as it is. d. Just my 2p. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re: Jakarta Overview
+1 - I'd like to see the detractors patch it as they see fit. On Tue, 19 Mar 2002 08:56:31 -0800 Daniel Rall [EMAIL PROTECTED] wrote. Ted Husted [EMAIL PROTECTED] writes: http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. I would be in favor of having the overview linked off of the About Jakarta section of the left nav. Index: project.xml === RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v retrieving revision 1.28 diff -u -u -r1.28 project.xml --- project.xml17 Mar 2002 11:20:42 - 1.28 project.xml19 Mar 2002 16:55:55 - @@ -17,6 17,7 @@ menu name=About Jakarta item name=Welcome href=/index.html/ item name=News Status href=/site/news.html/ item name=Overview href=/site/overview.html/ item name=Our Mission href=/site/mission.html/ item name=Our FAQs href=/site/faqs.html/ item name=Reference Library href=/site/library.html/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: Jakarta Overview
I'm -1 until someone can clarify how/why this is different from the Jakarta Subprojects section of the home page. Why not just add status information to that listing, if that's where the value-add is? How many places do we expect developers to update/document the status of their projects? -Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 11:16 AM To: [EMAIL PROTECTED] Subject: Re: Re: Jakarta Overview +1 - I'd like to see the detractors patch it as they see fit. On Tue, 19 Mar 2002 08:56:31 -0800 Daniel Rall [EMAIL PROTECTED] wrote. Ted Husted [EMAIL PROTECTED] writes: http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. I would be in favor of having the overview linked off of the About Jakarta section of the left nav. Index: project.xml === RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v retrieving revision 1.28 diff -u -u -r1.28 project.xml --- project.xml17 Mar 2002 11:20:42 - 1.28 project.xml19 Mar 2002 16:55:55 - @@ -17,6 17,7 @@ menu name=About Jakarta item name=Welcome href=/index.html/ item name=News Status href=/site/news.html/ item name=Overview href=/site/overview.html/ item name=Our Mission href=/site/mission.html/ item name=Our FAQs href=/site/faqs.html/ item name=Reference Library href=/site/library.html/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Ted Husted [EMAIL PROTECTED] writes: http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. I would be in favor of having the overview linked off of the About Jakarta section of the left nav. Index: project.xml === RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v retrieving revision 1.28 diff -u -u -r1.28 project.xml --- project.xml 17 Mar 2002 11:20:42 - 1.28 +++ project.xml 19 Mar 2002 16:55:55 - @@ -17,6 +17,7 @@ menu name=About Jakarta item name=Welcome href=/index.html/ item name=News amp; Status href=/site/news.html/ +item name=Overview href=/site/overview.html/ item name=Our Mission href=/site/mission.html/ item name=Our FAQs href=/site/faqs.html/ item name=Reference Library href=/site/library.html/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
On Tue, 2002-03-19 at 18:01, Daniel Rall wrote: Waldhoff, Rodney [EMAIL PROTECTED] writes: I'm -1 until someone can clarify how/why this is different from the Jakarta Subprojects section of the home page. One difference that I've noticed is that overview.xml is a more complete and comprehensive list of projects, where as the Subprojects section is missing quite a few -- I speculate that it may only be listing first-tier Jakarta projects, rather than their sub-projects as well (which are often times quite different and worth listing somewhere other than the home page of the first-tier projects). Why not just add status information to that listing, if that's where the value-add is? How many places do we expect developers to update/document the status of their projects? seems like a good place for some kind of include facility I'm no such a fan of the status information myself, but really like the comprehensive listing. -- 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]
RE: Re: Jakarta Overview
On Tue, 2002-03-19 at 13:05, Waldhoff, Rodney wrote: I'm -1 until someone can clarify how/why this is different from the Jakarta Subprojects section of the home page. Why, perhaps it needs expansion! I look forward to reading it *duck* -Andy documentation lover O. Why not just add status information to that listing, if that's where the value-add is? How many places do we expect developers to update/document the status of their projects? -Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 19, 2002 11:16 AM To: [EMAIL PROTECTED] Subject: Re: Re: Jakarta Overview +1 - I'd like to see the detractors patch it as they see fit. On Tue, 19 Mar 2002 08:56:31 -0800 Daniel Rall [EMAIL PROTECTED] wrote. Ted Husted [EMAIL PROTECTED] writes: http://jakarta.apache.org/site/news.html#0319 Thank you for your contribution. I would be in favor of having the overview linked off of the About Jakarta section of the left nav. Index: project.xml === RCS file: /home/cvs/jakarta-site2/xdocs/stylesheets/project.xml,v retrieving revision 1.28 diff -u -u -r1.28 project.xml --- project.xml 17 Mar 2002 11:20:42 - 1.28 project.xml 19 Mar 2002 16:55:55 - @@ -17,6 17,7 @@ menu name=About Jakarta item name=Welcome href=/index.html/ item name=News Status href=/site/news.html/ item name=Overview href=/site/overview.html/ item name=Our Mission href=/site/mission.html/ item name=Our FAQs href=/site/faqs.html/ item name=Reference Library href=/site/library.html/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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: Jakarta Overview
first, good effort. Thanks. I am not deeply familiar with many of the Jakarta projects (in particular, I can't quite fathom the full extend of some of the frameworks, such as Avalon or Turbine, at this time), but in the spirit of 'release-early/release-often' I would like to make the information I have compiled so far available to the community. subsection name=Avalon !-- purported benefits of Avalon are hard to find out! -- the same as for any framework, mostly. where it says reusable components, best-of-practice pattern enforcements, etc, you'll find commercial companies talking about how it redefines the way you work, allows faster time-to-market, keep your programmers happy, etc etc. When .Net was first announced, did you have any idea what it was about? libFramework/b !-- No overview or list of features and functionalities -- pThe Avalon framework consists of interfaces that define relationships between commonly used application components, best-of-practice pattern enforcements, and several lightweight convenience implementations of the generic components./p i.e. the main feature is that it does some thinking work for you. It is easy to write bad software using Java. It becomes somewhat more difficult if you use Avalon. So, avalon framework itself has no simple real-life functionality (ie HTTP server). libPhoenix/b pMinimal Application Server (manages classloader, security and logging needs)/p pPurpose somewhat unlear, possibly still starting out./p phoenix is not an application server in the normal sense. Its a micro-kernel, which is something different. ul libDocumentation:nbsp;/bVery sketchy/li While this is true, I would appreciate it not to list something like this on the front page. It encourages people not even to look into the available docs, so to speak. libDocumentation:nbsp;/bExtensive: Several Overview documents, HowTos, Javadoc. Apparently no worked Hello world example./li It doesn't make sense to have turbine say hello world when it includes Velocity, which is there to talk to the world. In short, some projects on jakarta are not easy to capture in 'marketing' terms, because they have a possibly very wide scope. I don't think we should even attempt to do so for projects still in alpha (ie phoenix). regards, - Leo Simons -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Overview
Waldhoff, Rodney [EMAIL PROTECTED] writes: I'm -1 until someone can clarify how/why this is different from the Jakarta Subprojects section of the home page. One difference that I've noticed is that overview.xml is a more complete and comprehensive list of projects, where as the Subprojects section is missing quite a few -- I speculate that it may only be listing first-tier Jakarta projects, rather than their sub-projects as well (which are often times quite different and worth listing somewhere other than the home page of the first-tier projects). Why not just add status information to that listing, if that's where the value-add is? How many places do we expect developers to update/document the status of their projects? I'm no such a fan of the status information myself, but really like the comprehensive listing. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
