FW: grammer issue
-Original Message- From: Dave Palmer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 19, 2002 3:09 PM To: [EMAIL PROTECTED] Subject: grammer issue Hello, Just thought I'd drop you a quick line to let you know that there is a slight grammer issue on the home page of the jakarta site: Please considerate and do your homework before asking our volunteers to donate additional time and energy to your project. I think you mean: Please be considerate... :) Keep up the excellent work! ./dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Problem installing Jarkarta-Tomcat
I think idiot was chosen because the person would have had to browse past the mail page with all the rules and then go to the other page. So had they taken the time to read any of the first page, then they'd have known where to post. Anyone object to me moving the general list to the bottom of the listings? -Andy On Wed, 2002-02-20 at 02:58, Endre Stølsvik wrote: On Tue, 19 Feb 2002, Danny Angus wrote: | Hi, | although this question would be more likely to get an accurate answer on the | tomcat mailing lists: http://jakarta.apache.org/site/idiot.html idiot.html - no less. How _nice_.. What about ignorant or some other not so rude word? -- Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel 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: ApacheForge
Vladimir Bossicard wrote: Apache is and has always been selective for a reason: we value communities more than software and it takes a lot of energy to build a community solid enough to build good enough software to pay back Apache for the risk of diluting the brand each time a new effort is added. The question is: what comes first? Do you first need a good software and then build a community around it or the opposite? In my experience, OSS communities never develop without software and without one individual to step to the plate and make things happening. Apache.org value communities and that's fine. But how do you build such a strong community when you just start a new project? You have no functional application, no developers and no users. Ask Linus, ask Larry, ask Guido, ask every single individual who was able to create a community out of its own energy. And look at Log4j, look at POI, look at BCEL, look at Lucene, look at FOP, look at XIndice, just to name a few: they were all able to build a community on their own, thus they were entitled to get in. Apache is not an ivory tower, Paul, is just seriously concerned about the balance between energy that goes *to* a project and energy that comes *back*. In order cross-pollinate between communities and in order for them to scale (in size and number), we must be *very* concerned about this balance, between social energy that we have to give to the project to bootstrap and how much of this comes back, possibly amplified. Sourceforge (and GNU, for what matters) don't care if projects die, we do. In fact, it's a rare event that a software project hosted under Apache dies out. I think that SourceForge is a real great tool if you want to start something new without knowing if it's a good idea, if it will be used and supported by other developers. If it fails... well you have at least tried. But SourceForge is not a community where people can exchange advises and experiences. It's basically do all mistakes yourself. You cannot start a serious project without having CVS, ML, bug tracking and release directory and SourceForge offers that for free, without having to ask for an Apache account (it will be rejected due to the lack of developers/users anyway). If Apache wants to attract more projects/developers, I think that it can use SourceForge's ressources (CVS...) and play more a mentoring/advisor role. Using Jon's terms: thansk for volunteering. In case you didn't notice, mentoring/advising is a very time-intensive role. What you say is perfect: there is room for something in between Apache and SourceForge and ApacheForge would fit that role. But the lack of *resources*, expecially human resources (even if the technical ones will be very hard to find too, believe me!), will destroy the issue from day one. So: *if* we had the human resources *if* we had a way to protect the brand (with a different domain name so that people have @apacheforge.org accounts and not @apache.org which are a different thing) *if* we had the technical resources *if* we had a serious rating system that would indicate when a project is *healthy* enough to be brought to apache.org *if* we thought this was valuable to the entire ASF effort then apacheforge.org would be a good idea. Unfortunately, not a single of those *if* is satisfied. If you're a hockey team, you need farm teams to let young players make their experiences. But young players need coaches. And coaches have families, need to eat, sleep and have a life. And a few coaches can't mentor a thousand projects effectively. So, we choose to stay at the window and do recruiting as the big teams do, instead of using our scarce resources to build our 'incubating' teams. Painting this as an ivory tower is, IMHO, a clear misunderstanding of the Apache spirit. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. [EMAIL PROTECTED] Friedrich Nietzsche -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ApacheForge
And look at Log4j, look at POI, look at BCEL, look at Lucene, look at FOP, look at XIndice, just to name a few: they were all able to build a community on their own, thus they were entitled to get in. Log4J was hosted on SourceForge POI was hosted on SourceForge BCEL was hosted on SouceForge My point is that you need 'a' SourceForge to start your project. Sourceforge (and GNU, for what matters) don't care if projects die, we do. In fact, it's a rare event that a software project hosted under Apache dies out. And I think it's good if projects die. It's part of a natural selection. If Apache wants to attract more projects/developers, I think that it can use SourceForge's ressources (CVS...) and play more a mentoring/advisor role. Using Jon's terms: thansk for volunteering. How can I volunteer since I don't have one single experience of the Apache community? In case you didn't notice, mentoring/advising is a very time-intensive role. Trying to build my own community right now and it's quite time-consuming, I agree. What you say is perfect: there is room for something in between Apache and SourceForge and ApacheForge would fit that role. I didn't say that. I only suggested that Apache should show the path from SourceForge to Apache. You can use SF's ressources (I don't think that setting up a new CVS repository does solve anything) but it's more important to present what Apache requires to enter into the club. When I started my project, I took a deep deep look at several Apache projects: - how they wrote the build file - how they organized the cvs tree - where they placed the license - how they named the packages - how they wrote their websites Several articles exist on the internet about these subjects, but I didn't find these things stated on the Apache website. And coaches have families, need to eat, sleep and have a life. That's why there are manuals. Young players can read them without bothering the coach. But I haven't found an 'Apache' manual. Painting this as an ivory tower is, IMHO, a clear misunderstanding of the Apache spirit. Apache is a club and it's not easy to join in. If you're outside this club, it can be viewed as an ivory tower. -Vladimir -- Vladimir Bossicard www.bossicard.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ApacheForge
on 2/20/02 8:35 AM, Vladimir Bossicard [EMAIL PROTECTED] wrote: But I haven't found an 'Apache' manual. Because it would take a HUGE amount of effort to create and maintain a manual like that. The people who know the manual don't have the itch to create the manual because there is always people who are coming along who have enough of a clue and drive to figure out the manual on their own. Nice catch-22. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ApacheForge
Jon Scott Stevens [EMAIL PROTECTED] wrote: on 2/20/02 8:35 AM, Vladimir Bossicard [EMAIL PROTECTED] wrote: Log4J was hosted on SourceForge POI was hosted on SourceForge BCEL was hosted on SouceForge My point is that you need 'a' SourceForge to start your project. No you don't. http://share.whichever.com It is just more 'convenient' for developers to use SF. As well on our small sites... http://eas.betaversion.org/index.jsp ... Ask and thou shall be given (if I like you! SourceForge doesn't actually have the I like you requirement, though! :) :) :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ApacheForge
on 2/20/02 9:22 AM, Jon Scott Stevens [EMAIL PROTECTED] wrote: on 2/20/02 8:35 AM, Vladimir Bossicard [EMAIL PROTECTED] wrote: But I haven't found an 'Apache' manual. Because it would take a HUGE amount of effort to create and maintain a manual like that. The people who know the manual don't have the itch to create the manual because there is always people who are coming along who have enough of a clue and drive to figure out the manual on their own. Nice catch-22. -jon That said, I will do my best to support someone who wants to create a manual like that. If you hang around here and watch what happens and how people do things and start to document it. Then I promise to review it and comment on it. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
New sites using Jakarta's projects
Dear Jakarta Team and contributors, I'm proud to let you know that the city of Paris is about to release 21 official sites mainly powered by Jakarta projects and free softwares (Linux, MySQL,..). Our project is based on Java-XML portals that share content through a common database and XML documents. This project will use 63 MySQL databases and 42 webapps. The first site is online at http://www.mairie3.paris.fr/ and the others should be opened before this summer. Have a look to Credits popup for more detailed information on components we used (I'm sure you will understand some French ;-)). Thanks for your HQ sofwares and keep up the great work. Very Sincerely Pierre LEVY Senior Software Engineer City of Paris - France [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Apache Manual (was ApacheForge)
Jon, Give us a TOC for what you think might be a good starting point. That said, I will do my best to support someone who wants to create a manual like that. If you hang around here and watch what happens and how people do things and start to document it. Then I promise to review it and comment on it. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ApacheForge
Vladimir Bossicard [EMAIL PROTECTED] wrote: When I started my project, I took a deep deep look at several Apache projects: - how they wrote the build file - how they organized the cvs tree - where they placed the license - how they named the packages - how they wrote their websites Several articles exist on the internet about these subjects, but I didn't find these things stated on the Apache website. To help myself, and possibly also others, start projects in Apache-style, I set up a new project on Sourceforge called Krysalis (krysalis.org). At present, there is not much there as documentation yet, but the project itself tries to conform to what is normal practice at jakarta and xml.apache. Currently there is Centipede 0.1, a simple starter project for a software module that uses Ant for the build and with Apache Cocoon for Site+Documentation. The new POI project developers are using it and are giving me lots of tips and help to make it better. Stefan Bodewig has kindly put a link to this project on the Ant -related projects- page, and I will do my best to collaborate with all the Apache projects I use and appreciate. Jon Scott Stevens [EMAIL PROTECTED] wrote: I will do my best to support someone who wants to create a manual like that. If you hang around here and watch what happens and how people do things and start to document it. Then I promise to review it and comment on it. Cool! :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache Manual (was ApacheForge)
Why not start it yourself and anyone can suggest changes. On the other hand, why not start it myself. Something like this: 1.- Introduction Who we are, why are we doing this. 2.- Project proposal Proposal stage, committers needed, community. 3.- Code organization and repositories Naming of packages, repositories, what to find in them. Who touches what. 4.- Code quality Add copyright notice, add authors. Format your code but not others'. 4.- Build system Use Ant, use Ant, use Ant. Use Gump. Use Scarab. 5.- Dependencies What jar's to use and what to avoid. 6.- Documentation Where to look for it. What to expect, what not to expect. 7.- Support Whom you should ask, what you should figure out yourself. 8.- Licensing and guarantee Why you should use Apache license, and what's wrong with other licenses. What you can do with Apache products. Giving credit. All that implied warranty things. Un saludo, Alex. -Mensaje original- De: Paul Hammant [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 20 de febrero de 2002 18:51 Para: Jakarta General List Asunto: Apache Manual (was ApacheForge) Jon, Give us a TOC for what you think might be a good starting point. That said, I will do my best to support someone who wants to create a manual like that. If you hang around here and watch what happens and how people do things and start to document it. Then I promise to review it and comment on it. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: EJB = bad = MS.net
That sounds more like opinion than fact. EJB's seem to work fine, and do a good job, where they fit. Why would you say that if you use EJBs you'll have to use .CRAP? On Wed, 2002-02-20 at 11:42, Vic Cekvenich wrote: Home page of Jakarta has this http://jakarta.apache.org/site/news.html#0130.2 on this: http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html I agree. Doing EJBs is bad on many levels and creates more problems. Avoid EJB if you want to stay in Java. Alternative is to just use Struts + TomCat + RowSet (or DAO if you are doing something simple or small) and done. This is the sweet spot. MVC is all you need. Alternative, do EJBs and your organization WILL switch to MS .NET on the next project, leave J2EE, and you have to learn VB.net. EJBs are for newbies. (If you need middleware (very rare) use SOAP) lol, Vic -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: [EMAIL PROTECTED] It is the part of a good shepherd to shear his flock, not to skin it. Latin Proverb -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache Manual (was ApacheForge)
I don't think you understood what I said...so let me repeat... You give me a TOC and I will review and comment on it. :-) -jon on 2/20/02 9:50 AM, Paul Hammant [EMAIL PROTECTED] wrote: Jon, Give us a TOC for what you think might be a good starting point. That said, I will do my best to support someone who wants to create a manual like that. If you hang around here and watch what happens and how people do things and start to document it. Then I promise to review it and comment on it. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache Manual (was ApacheForge)
on 2/20/02 10:03 AM, Fernandez Martinez, Alejandro [EMAIL PROTECTED] wrote: Why not start it yourself and anyone can suggest changes. I love it when people 'get it'. :-) On the other hand, why not start it myself. Something like this: You kick ass. Note that the majority of your bullet points are already in some form of documentation on the website that no one bothers to read. 1.- Introduction Who we are, why are we doing this. http://jakarta.apache.org/site/whoweare.html 2.- Project proposal Proposal stage, committers needed, community. http://jakarta.apache.org/site/getinvolved.html http://jakarta.apache.org/site/newproject.html 3.- Code organization and repositories Naming of packages, repositories, what to find in them. Who touches what. http://jakarta.apache.org/site/guidelines.html 4.- Code quality Add copyright notice, add authors. Format your code but not others'. http://jakarta.apache.org/site/dirlayout.html http://jakarta.apache.org/site/agreement.html 4.- Build system Use Ant, use Ant, use Ant. Use Gump. Use Scarab. Not done yet. 5.- Dependencies What jar's to use and what to avoid. http://jakarta.apache.org/site/jars.html 6.- Documentation Where to look for it. What to expect, what not to expect. Not done yet. 7.- Support Whom you should ask, what you should figure out yourself. http://jakarta.apache.org/site/mail.html 8.- Licensing and guarantee Why you should use Apache license, and what's wrong with other licenses. What you can do with Apache products. Giving credit. All that implied warranty things. http://www.apache.org/foundation/licence-FAQ.html -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
EJB = bad = MS.net
Home page of Jakarta has this http://jakarta.apache.org/site/news.html#0130.2 on this: http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html I agree. Doing EJBs is bad on many levels and creates more problems. Avoid EJB if you want to stay in Java. Alternative is to just use Struts + TomCat + RowSet (or DAO if you are doing something simple or small) and done. This is the sweet spot. MVC is all you need. Alternative, do EJBs and your organization WILL switch to MS .NET on the next project, leave J2EE, and you have to learn VB.net. EJBs are for newbies. (If you need middleware (very rare) use SOAP) lol, Vic -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Apache Manual (was ApacheForge)
Alex, That's a really good start. My only comment right now is to point out that some of the topics in this list are Jakarta specific and Apache is much bigger than Jakarta. It would be cool if a manual such as this covered how other Apache projects handle similar tasks. I'd also include a chapter on Apache and Jakarta rules. For example, voting rules, what constitutes a valid vote, what are the voting types and when they apply, what are meanings of +1/+0/0/-0/-1 in the various voting types. A collection of release instructions for various projects might also be useful. When I was the release manager for Tomcat 3.2.x I got some initial help from Craig, but after that I had to invent most of the process myself (and I'll be the first admit that I didn't document that process :-( ). I'm sure I think of more after giving it some more thought. Good start, though. Marc Saegesser -Original Message- From: Fernandez Martinez, Alejandro [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 12:04 PM To: 'Jakarta General List' Subject: RE: Apache Manual (was ApacheForge) Why not start it yourself and anyone can suggest changes. On the other hand, why not start it myself. Something like this: 1.- Introduction Who we are, why are we doing this. 2.- Project proposal Proposal stage, committers needed, community. 3.- Code organization and repositories Naming of packages, repositories, what to find in them. Who touches what. 4.- Code quality Add copyright notice, add authors. Format your code but not others'. 4.- Build system Use Ant, use Ant, use Ant. Use Gump. Use Scarab. 5.- Dependencies What jar's to use and what to avoid. 6.- Documentation Where to look for it. What to expect, what not to expect. 7.- Support Whom you should ask, what you should figure out yourself. 8.- Licensing and guarantee Why you should use Apache license, and what's wrong with other licenses. What you can do with Apache products. Giving credit. All that implied warranty things. Un saludo, Alex. -Mensaje original- De: Paul Hammant [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 20 de febrero de 2002 18:51 Para: Jakarta General List Asunto: Apache Manual (was ApacheForge) Jon, Give us a TOC for what you think might be a good starting point. That said, I will do my best to support someone who wants to create a manual like that. If you hang around here and watch what happens and how people do things and start to document it. Then I promise to review it and comment on it. - Paul -- 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: New sites using Jakarta's projects
-Original Message- From: Levy, Pierre [mailto:[EMAIL PROTECTED]] Dear Jakarta Team and contributors, I'm proud to let you know that the city of Paris is about to release 21 [...] cool ! summer. Have a look to Credits popup for more detailed information on components we used (I'm sure you will understand some French ;-)). Apache Server, Tomcat, Xalan, Xerces, Jetspeed, Cocoon, Lucene Care to give the version used ? (apart from Apache 1.3.19) out of curiosity: - How many screens are in all webapps ? - How many people worked on it ? - How long did the development last ? ps: Didn't you use Ant, it's not in the credits ? :o) Cheers, Stephane. Jakarta Ant committer in Paris. ;-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Re: ApacheForge
-Original Message- From: acoliver [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 11:08 AM To: [EMAIL PROTECTED] Subject: Re: Re: ApacheForge Just FYI There is also the traffic issue. If you have an active project, sourceforge automatically publicizes the project on the front page. Although, alternative hosting was available for POI this was too valuable to pass up. (I have my own server www.superlinksoftware.com where POI started out) -Andy But Forrest will take care of that ;-) [EMAIL PROTECTED] Scott Sanders -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: EJB = bad = MS.net
Vic Cekvenich wrote: Home page of Jakarta has this http://jakarta.apache.org/site/news.html#0130.2 on this: http://www.mail-archive.com/general%40jakarta.apache.org/msg03376.html I agree. Doing EJBs is bad on many levels and creates more problems. Avoid EJB if you want to stay in Java. Alternative is to just use Struts + TomCat + RowSet (or DAO if you are doing something simple or small) and done. This is the sweet spot. MVC is all you need. Alternative, do EJBs and your organization WILL switch to MS .NET on the next project, leave J2EE, and you have to learn VB.net. EJBs are for newbies. (If you need middleware (very rare) use SOAP) Thanks for the convincing argument. So tell me how using Struts+Tomcat+RowSet you get: - location independence - distributed processing - failover and clustering support - transactional object behaviour for non-data classes - pooled business objects Ans since you're using SOAP, how do you handle things like massive object creation issues on the SOAP Server? Write all that infrastructure again? Sure why not. -- dIon Gillard, Multitask Consulting http://www.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
