RE: [Request For Comment] POI @ apache
Not necessarily true, I've worked on applications where a servers ability to dynamically create M$ documents is a cool feature, imagine a servelet which returned an xls workbook reporting on data from an ODBC datasource (maybe sales figures or contact details), people in M$ centered offices lap that up, particularly if it can include VBS macros providing an update path and other client-server features. There you have a client's (admitedly simple) route into a non M$ environment which doesn't frighten the children or use ODBC or any non M$ application on the client side. d. Geir Magnusson Jr. wrote: Sure, but the flip side of that is it's really more of a client-ish tool, as from what I gather it's focus is desktop-software documents (MSFT). Important, and rather cool that someone did it, but not strictly serverside. Of course, Jakarta isn't strictly server-side either. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Ted Husted wrote: At this point, I'm reconciled to do more work on the Jakata site using XML in the old-fashioned way. I can't resonate more with your feelings. That's exactly what made me started the 'forrest' effort: the coherence on xml.apache.org and the ease of update has been slowly falling apart until now when people can't even run in on their machines without getting fonts problems (yeah, blocked by fonts problems! go figure!) We have some unratified guidelines that expand on the ones (you?) originally set down. No, that wasn't me to edit that page, even if much was taken from my java.apache constitution (as you indicate below), which on my side, took from the old dev.apache.org guidelines for [EMAIL PROTECTED] http://jakarta.apache.org/site/proposal.html If you were able to review them, I would of course very much like to have your comments before making a final update and calling for a vote. I'm honored. I'll do it ASAP. I would also like to add more rationale for some of the guidelines. The recent dicussion regarding coding conventions had less to do with the conventions themselves, and more to do with why we even have conventions. (And having conventions, why don't we enforce them.) Good point. As Jakarta grows, it becomes more and more important that we have better ways to introduce peoole into the fold. Right now, there is a tendency to make someone a Committer and let them find their own way around. At this time, I'd like to go to work on a Committer's guidebook that would help explain how things are done (starting with How to do a Release -- which raised the JAR discussion the other day). Oh, gosh, you are probably unaware of the fact that I'm the one that continously pisses people off on the ASF member list (unfortunately private) about having those 'committer guidelines' up and running. James Davidson and I were the one who made the page on how to setup your SSH tunnel for CVS. Yes, this is the right direction, but people must commit to keep those guidelines up 2 date and many people (expecially apache root's) failed miserably to do it. Also we must make those easy to find. Again, Forrest will help. I think the real solution to improving the noise:signal ratio is to move away from the oral (email) tradition we have now, and move back toward providing more grassroots documentation, as you did in the preamble to the original constition. http://java.apache.org/main/constitution.html Absolutely. An actual history of Jakarta might also be useful to give people a better perspective. Here's one passages I tucked away (to be joined by your own snippets of late). Pier to Jon - Thu, 21 Dec 2000 We've traveled a long way together, from my very first steps in open-source land in January 1998, to our marvelous meeting at the first ApacheCON in October 1998, the Jakarta room meeting, all JavaONEs, and all we did together to bring this project where it is right now. Pier again, same day And we, as the newly formed Apache Software Foundation, accepted that code in donation as a point of start for the Jakarta Project. I was there, in that meeting room, that day when we outlined how the process would have evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE, when Patricia Sueltz announced the spinoff of the project againg with Jon, Stefano and Brian. If that has been a wrong decision, we four are the people to blame... A coherent history might help with many of the questions about why we do things the way we do. (Or why we don't do some things at all.) I think clearly documenting the Apache Way would be an important first step to unifying the Apache Projects. Great point. I absolutely agree. I would also like to personally commend Jon with his efforts to better document Jakarta. He has put a lot into the Web site (probably 90%), and we all owe him a great debt. Oh, I never even thought about questioning this. I personally owe everything to Jon: without his kind messages, I wouldn't have remained around the community enough to get the 'apache feeling' out of it. Jon and I have very different technical views and very different ways of doing software architectures and sometimes some friction develops, but all the times I land in SFO, he's the first one who I call to hang out with! :) [yeah, people, the 'rude' Jon Stevens was the one who gave Pier and I hospitality in his place when we came to ApacheCON 98 and we didn't have a place to stay since we had to pay our own expenses] Gosh, Ted, you're right, we should write this history down someplace and let people know how we came here. -- 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:
RE: On unity and coherence [was Re: [Request For Comment] POI @ apache]
As a newbie (only 1.5 years around) I found the small bio posted by Stefano on the Cocoon-dev list very interesting and instructive. This post was triggered by curiosity and know-your-community concerns that popped up in a couple of Cocoon-dev threads less than 2 months ago. IMO, the fact that it is written in the first person only helps. To ease the task of searching for it, I am just attaching it. Maybe Ted and others can use it as an historic source. Have fun, Paulo Gaspar -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 3:48 PM Ted Husted wrote: At this point, I'm reconciled to do more work on the Jakata site using XML in the old-fashioned way. I can't resonate more with your feelings. That's exactly what made me started the 'forrest' effort: the coherence on xml.apache.org and the ease of update has been slowly falling apart until now when people can't even run in on their machines without getting fonts problems (yeah, blocked by fonts problems! go figure!) We have some unratified guidelines that expand on the ones (you?) originally set down. No, that wasn't me to edit that page, even if much was taken from my java.apache constitution (as you indicate below), which on my side, took from the old dev.apache.org guidelines for [EMAIL PROTECTED] http://jakarta.apache.org/site/proposal.html If you were able to review them, I would of course very much like to have your comments before making a final update and calling for a vote. I'm honored. I'll do it ASAP. I would also like to add more rationale for some of the guidelines. The recent dicussion regarding coding conventions had less to do with the conventions themselves, and more to do with why we even have conventions. (And having conventions, why don't we enforce them.) Good point. As Jakarta grows, it becomes more and more important that we have better ways to introduce peoole into the fold. Right now, there is a tendency to make someone a Committer and let them find their own way around. At this time, I'd like to go to work on a Committer's guidebook that would help explain how things are done (starting with How to do a Release -- which raised the JAR discussion the other day). Oh, gosh, you are probably unaware of the fact that I'm the one that continously pisses people off on the ASF member list (unfortunately private) about having those 'committer guidelines' up and running. James Davidson and I were the one who made the page on how to setup your SSH tunnel for CVS. Yes, this is the right direction, but people must commit to keep those guidelines up 2 date and many people (expecially apache root's) failed miserably to do it. Also we must make those easy to find. Again, Forrest will help. I think the real solution to improving the noise:signal ratio is to move away from the oral (email) tradition we have now, and move back toward providing more grassroots documentation, as you did in the preamble to the original constition. http://java.apache.org/main/constitution.html Absolutely. An actual history of Jakarta might also be useful to give people a better perspective. Here's one passages I tucked away (to be joined by your own snippets of late). Pier to Jon - Thu, 21 Dec 2000 We've traveled a long way together, from my very first steps in open-source land in January 1998, to our marvelous meeting at the first ApacheCON in October 1998, the Jakarta room meeting, all JavaONEs, and all we did together to bring this project where it is right now. Pier again, same day And we, as the newly formed Apache Software Foundation, accepted that code in donation as a point of start for the Jakarta Project. I was there, in that meeting room, that day when we outlined how the process would have evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE, when Patricia Sueltz announced the spinoff of the project againg with Jon, Stefano and Brian. If that has been a wrong decision, we four are the people to blame... A coherent history might help with many of the questions about why we do things the way we do. (Or why we don't do some things at all.) I think clearly documenting the Apache Way would be an important first step to unifying the Apache Projects. Great point. I absolutely agree. I would also like to personally commend Jon with his efforts to better document Jakarta. He has put a lot into the Web site (probably 90%), and we all owe him a great debt. Oh, I never even thought about questioning this. I personally owe everything to Jon: without his kind messages, I wouldn't have remained around the community enough to get the 'apache feeling' out of it. Jon and I have very different technical views and very different ways of doing software architectures and sometimes some friction develops, but all the
RE: On unity and coherence [was Re: [Request For Comment] POI @apache]
Here we go again, -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 4:45 AM Playing Devil's advocate. I think it's fair to push back on adding things to Jakarta... On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? WHY for presentation? Most of the time you would batch convert Word and Excel docs to HTML if needed, and there are specialized tools for that. However, you point out in the above link that the thing that makes POI special is it's ability to *write*? What's the % of mainly writing to mainly reading on the serverside? As mentioned in my previous posting, it is JUST like Velocity writing HTML. http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html Paulo might use VB to make a client side app, but I wouldn't if I wanted portability, especially if I was looking to the handheld or embedded application that could access a document remotely... Are there many uses for writing Word/Excel documents in a client-side device that has not Word or Excel installed??? And AFAIK, if you have Word and Excel, you have at least some Basic scripting... but maybe you do not have Java. ... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
On 1/6/02 12:18 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: Here we go again, Alas. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 4:45 AM Playing Devil's advocate. I think it's fair to push back on adding things to Jakarta... On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? WHY for presentation? Most of the time you would batch convert Word and Excel docs to HTML if needed, and there are specialized tools for that. 'presentation' in the sense of 'reading data out to show in some manner', not 'on the desktop'. However, you point out in the above link that the thing that makes POI special is it's ability to *write*? What's the % of mainly writing to mainly reading on the serverside? As mentioned in my previous posting, it is JUST like Velocity writing HTML. Huh? You have to explain that a little more - I don't quite get it. http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html Paulo might use VB to make a client side app, but I wouldn't if I wanted portability, especially if I was looking to the handheld or embedded application that could access a document remotely... Are there many uses for writing Word/Excel documents in a client-side device that has not Word or Excel installed??? You might find this unbelieveable, but not everyone works on a computer that runs an operating system that has Word or Excel available. And AFAIK, if you have Word and Excel, you have at least some Basic scripting... but maybe you do not have Java. ... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: On unity and coherence [was Re: [Request For Comment] POI @apache]
Again... -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 6:14 PM On 1/6/02 12:11 PM, Paulo Gaspar [EMAIL PROTECTED] wrote: ... Lots of is it server or is it client talk ... I just mean that sometimes saying that something is server-side or client-side just makes no sense. As Ceki puts it, maybe JMeter is one of the few clearly server-side products in Jakarta. BTW... is Log4J server-side? =;o) From what I read, POI is an API that accesses data in XLS files... Theres a huge difference. And Cocoon isn't part of Jakarta, is it? :) JUST because it is XML centric, which POI is not. Right. I wasn't advocating it going to XML-land - it doesn't seem to belong there either. It am still not aware of any valid argument that clearly states why it does not belong to Jakarta or why it belongs. It is just like BCEL or Log4J - some people wanted those projects here because they had use for them or were already using them. Nothing to do with serversideness!!! BTW, do you know they use Velocity for something??? Who, POI? NO! Cocoon! ... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
On Mon, 7 Jan 2002 04:14, Geir Magnusson Jr. wrote: BTW, do you know they use Velocity for something??? Who, POI? Cocoon have a VelocityGenerator (the first stage in their XML transformation pipeline). -- Cheers, Pete -- you've made a dangerous leap right over common sense, like some kind of metaphysical Evil Knievel -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: On unity and coherence [was Re: [Request For Comment]POI@apache]
Answer inline -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 3:53 AM ... I can not express this POV better than Linus did in posts reported by this article: http://kerneltrap.org/article.php?sid=398 Any corporation organizizes things and I do not see better user understanding there. My viewpoint is a bit different then Linus on some things. Keep in mind that Linus does not favor complete anarchy, as is obvious from the grip he has on Linux. Yes. Linus has different beliefs in release management. I'm a bit more disciplined in style. Don't get me wrong, Linus is like my idol and all, just I bet I'm far more likely to do a sequence diagram or write documentation. We have different viewpoints on a lot of different things. Yet I don't care to maintain as tight of control over POI. I'd exert my say if say someone wanted to do the equivalent of maybe embed X inside the kernel (like the whole thing) directly, but mostly I don't try to direct things quite as much in some areas. The point is that too many restrictions are bad. The problem is to find out what too many is. IMO, things can be improved but the main problem is not lack of rigid discipline. true, I wasn't meaning to say rigid discipline would. As an example of too many or too less restrictions, I believe that: - forcing every project to follow the same code conventions would be counterproductive; Completely and TOTALLY agree. - forcing each project to have explicit code conventions and follow them would be just fine. As long as those projects can have explicitly lax coding conventions in places where others would be more rigid. (POI - write good code. be self consistent and we all kinda agree that embedded ternary operators is the most evil sin of all) It is good to have diversity. There is the cross pollination effect and there is also the fact that what one group things is better is not so sure that it should be imposed. +1 Besides, there is no such thing as an Open Source external customer. Those that contribute to it (the authors and even noisy guys like me) ARE the customers. People PAY Open Source by participating. If something is wrong FIX IT! I don't completely agree with you on that. Some contributions to Open Source are less quantifiable than others. I see I'm a bit morecommunistic. I'm so far the the left on this that I'm on the right? I doubt you are that different. *Looks down at his cookie monster slippers* is not withing to POI's mission, that won't fly. (There will be NO GUI components in POI)... If they feel like working on a feature that I just don't think is in our critical path...go at it. So, you try to keep people happy but you are not so communistic that you make everybody happy (which would be crazy, I agree). Which reminds me of an Abe Lincoln quite. Anyhow I contributed ideas. Take them for what they were. They were NOT complaints. Apache is the most healthy opensource group there is. (its healthier then GNU IMHO) I also believe so, of course. You probably know what I am talking about since POI is Open Source. POI is opensource, there are some differences of opinion between you and I on who the contributers are. To me: User: doesn't submit patches, but uses the software. The more people who USE POI the better and healthier POI is. For example. A user the other day sent a bug. He had an toasted XLS file. It had confidential data in it so he couldn't contribute a sample. I talked him through running HSSF through a debugger and he found the problem. HSSF 1.0.1 can't handle cells with strings over 15,000 characters long if they don't occur early in the file. (there is a static string table and it is kinda blocked or paged). You are talking about users that contribute something to the projects: they test it, report problems and help making it more solid that way. I still do not see any difference in your opinion. Gotcha. It often does not seem that many agree with this viewpoint. In my posting I even including this paragraph: Besides, there is no such thing as an Open Source external customer. Those that contribute to it (the authors and even noisy guys like me) ARE the customers. Noisy guys like me means I only contributed a couple of patches but I still like to think that the some of the ideas I dumped on Jakarta lists are worth something (hey, some of them did result on something besides flames). +1 Gotcha. I missed your meaning before. One way or the other, I am involved. I am NO external customer. Even if many times just with ideas, I try to influence and contribute to the evolution of the products I use. yup. And when I see no possibility of changing the product in the way it suites my needs, I fork and still save a lot of work. Like I said. I see the fork as something to generally be avoided unless there is
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Stefano Mazzocchi wrote: In my mind, all this long trail of thoughs yields the following equation: metacommunity size * community coherence * individual freedom = constant in result, if we unify the two projects, we double the size of the metacommunity and we must pay the price of decreased coherence and/or decreased individual freedom. So, if we half the community size we double the coherence and/or individual freedom? What happens if we half it again? Hmmm. I guess the optimum community size is 1. Reductio ad Absurdum I think this equation misses the important second order affects of collaboration. My feeling is that communities need a critical mass, as do meta-communities. I'm not sure what that size is, but in my mind the XML project has not reached it. And it is not just size that is the issue, it is the presence (or lack) of people who cross pollinate ideas. Within Jakarta, this is being done on an ever increasing scale. Perhaps a metric that would be more useful is to contemplate the size of the intersection between the subscribers to any two mailing lists picked at random. Without looking, it is clear to me that however you choose to quantify this metric, Jakarta would greatly exceed XML. What you have observed lately has been a spike of activity on the general mailing list. One thread dealt with the ever popular coding style issues (which unfortunately overwhelmed the more important underlying issue that Jon was trying to get us to face). The other thread dealt with the intentionally high threshold that we have for accepting new Jakarta projects. Now for a thought experiment: if POI were added to Jakarta, would this metric overall increase or decrease for Jakarta? If POI were added to XML, would the metric overall increase or decrease? Ignoring the fact that the following are clearly related, which is more important: community coherence or mission coherence? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
At 10:40 AM 1/5/02 -0500, you wrote: I would also like to personally commend Jon with his efforts to better document Jakarta. He has put a lot into the Web site (probably 90%), and we all owe him a great debt. -Ted. Despite Jon's candid remarks, as you put it, Ted, I too would like him to know that I join a throng in saying thanks. - Micael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Request For Comment] POI @ apache
Hi Paulo, IMO Andrew puts the finger on why POI is only used on a server. good! One of my 2 interests (the other is indexing) on POI is exactly the typical one he describes: - I want to be able build Word and Excel documents on a Web Server without going back to use MS IIS and COM automation. (... even because using COM to control Word/Excel in a multithreaded application sounds VERY problematic and all the other methods I can think of are some other kind of PITA.) You got it exactly. Feel free to join us on the poi-devel or poi-general-users lists (http://poi.sourceforge.net). Apparently many people share your interest: The POI project climbed to #4 on the charts today. Hey, for a client application, I would use Delphi or VB + COM in Windows and something around OpenOffice in Linux. Complete agreement. For a client app where you know what your client is (and with an office doc you probably know who your client is), there would be little reason to use POI (other than the office automation API in VB is kind of a pain to use because its based on programmaticly simulating the user which can be painful). I'm not sure there would be a reason to use Java (most things could probably be done as a big fat Excel macro for instance). Hey! I am just finding out how much server side POI really is!!! Glad that shined the light. Have fun, Definitely! Paulo Gaspar Thanks! -Andy -- 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: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Hello, Each structure has a cost depending on his level of organization. I think there is today to many project in the jakarta and the xml project. I feel confuse about finding the right information at the right place. And I think it's high time to merge xml and jakarta. The way java is organizing code in package is rather simple and efficient, maybe organizing project this way is the solution. We should debate about this organization. I propose some package organization : XML(Xerces,Crimson) XSL(Xalan,FOP) SVG(Batik) WebApps(Cocoon, JetSpeed...) JSP (TagLibs) FrameWork(Turbine, Avalon, Struts..) Project Management (Ant, Slide) Metric Testing (Log4J, WatchDog) ToolBox(ORO, RegExp, Lucene) ... I'd like your opinion about it, which package with which existing project. Ciao Chris - agitateur depuis toujours *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
At 15:31 05.01.2002 +0100, Stefano Mazzocchi wrote: [Snip] In my mind, all this long trail of thoughs yields the following equation: metacommunity size * community coherence * individual freedom = constant This equation is misleading. Coherence and individual freedom are not inversely proportional, perhaps related but not inversely proportional. That much is certain. in result, if we unify the two projects, we double the size of the metacommunity and we must pay the price of decreased coherence and/or decreased individual freedom. But are we sure the pros outweight the cons? No, we can't be sure. The experiment cannot be undone and started over. Anyway, contrary to my previous hints, I am unsure if having XML and Jakarta would benefit either Jakarta or XML. If someone cares enough about a particular XML project nothing keeps him/her from participating in that project. IMHO, XML does not and will never have a community as long as two of its most important projects directly compete with each other. The success of one is related with the failure of the other. XML Community? Won't happen in a million years. How the did Crimson become an Apache project anyway? Unity and coherence (the subject of this thread) are strongly related to management and decision making. Since we don't have a manager, we must have a healthy decision making process. The current system of voting where each participant is granted veto power is a system geared towards non-decision making. This was perhaps one of the intentions of the founders of the ASF. Anyone know where -1 tradition came from? My suggestion is institute a new tradition where members of the community can make proposals which the community votes on. Advantages: decisions can be made. Disadvantages: decisions can be made. The required majority for the adoption of proposals can be simple or qualified. Even if the qualified majority is 3/4, this would be better than the veto system we have today. Although a veto can be overridden by a 3/4 majority, as far as I know, this has never happened in the past. Today someone voting -1 means end of discussion. I dare anyone to -1 that. Regards, Ceki -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Chris, I think you are confusing project categorization with project community. These things are very much unrelated. Regards, Ceki At 23:44 05.01.2002 +0100, you wrote: Hello, Each structure has a cost depending on his level of organization. I think there is today to many project in the jakarta and the xml project. I feel confuse about finding the right information at the right place. And I think it's high time to merge xml and jakarta. The way java is organizing code in package is rather simple and efficient, maybe organizing project this way is the solution. We should debate about this organization. I propose some package organization : XML(Xerces,Crimson) XSL(Xalan,FOP) SVG(Batik) WebApps(Cocoon, JetSpeed...) JSP (TagLibs) FrameWork(Turbine, Avalon, Struts..) Project Management (Ant, Slide) Metric Testing (Log4J, WatchDog) ToolBox(ORO, RegExp, Lucene) ... I'd like your opinion about it, which package with which existing project. Ciao Chris - agitateur depuis toujours *** -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
Ceki Gülcü wrote: IMHO, XML does not and will never have a community as long as two of its most important projects directly compete with each other. The success of one is related with the failure of the other. XML Community? Won't happen in a million years. How the did Crimson become an Apache project anyway? Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and Crimson. The developers *are* working together. I won't pretend that everything is 100% smooth sailing, but significant progress is being made. The required majority for the adoption of proposals can be simple or qualified. Even if the qualified majority is 3/4, this would be better than the veto system we have today. Although a veto can be overridden by a 3/4 majority, as far as I know, this has never happened in the past. Today someone voting -1 means end of discussion. I dare anyone to -1 that. Regards, Ceki The rules you describe don't look familiar to me. The ones I am familiar with are: http://jakarta.apache.org/site/decisions.html http://jakarta.apache.org/site/management.html - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]
At 18:02 05.01.2002 -0500, you wrote: Ceki Gülcü wrote: IMHO, XML does not and will never have a community as long as two of its most important projects directly compete with each other. The success of one is related with the failure of the other. XML Community? Won't happen in a million years. How the did Crimson become an Apache project anyway? Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and Crimson. The developers *are* working together. I won't pretend that everything is 100% smooth sailing, but significant progress is being made. Point well taken. The required majority for the adoption of proposals can be simple or qualified. Even if the qualified majority is 3/4, this would be better than the veto system we have today. Although a veto can be overridden by a 3/4 majority, as far as I know, this has never happened in the past. Today someone voting -1 means end of discussion. I dare anyone to -1 that. Regards, Ceki The rules you describe don't look familiar to me. The ones I am familiar with are: http://jakarta.apache.org/site/decisions.html http://jakarta.apache.org/site/management.html My mistake. I was always under the impression that new project creation required a 3/4 vote *and* no binding vetoes (which I admit makes no sense). Thanks for the clarification. Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
on 1/5/02 3:02 PM, Sam Ruby [EMAIL PROTECTED] wrote: Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and Crimson. The developers *are* working together. I won't pretend that everything is 100% smooth sailing, but significant progress is being made. Yea...just like Tomcat 3x and Tomcat 4x...suuueee... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
Not that I should have much of a role in this discussion but I'd like to contribute some thoughts stemming from an offline discussion I had. I think this discussion is still missing the point. There are a lot of outsider articles on what is wrong with Apache these days, most of them refer to the total disinterest (by many developers in the projects) on the market meaning what do the user's actually want. I'd say this is a component. (Please take this as somewhat of an outsider who has a lot of experience with Apache work-products) (as a symptom of this: Apache is OBVIOUSLY a better Web Server, TOMCAT is obviously a better App server of sorts, and though not a apache project JBOSS is a great enterprise serverso why is IIS gaining ground despite its overall suckiness?) The second component is an overall lack of unity-of-purpose. XML.apache.org hasn't reached a critical mass and in my opinion may never because it does have unity-of-purpose and I think that is part of why Stefano recommended I approach Jakarta first. POI has a lot to contribute to XML.apache.org but it has a lot of stuff that *would* contribute more to Jakarta's purpose if it had one. This isn't a slam, hear me out. The Apache group had a unity of purpose early on. They had a product: a webserver. Everything that Apache did had something directly to do with that product. Some things were semi-independent so subgroups seemed like the best way to handle it. Java-Apache had this unity-of-purpose: Java on Apache. Well for Java on Apache you need a mod to handle that (since everything is a mod in Apache) so you get mod-jserv, of course you have a lot of things that roll in and out of that based on serverside components for developing with your java mod. But you have unity-of-purpose. (or at least for a time) What is Jakarta's mission? server side java stuff. What is your product (look at the homepage)whoa thats a big list of subprojects... Wait is ant a server side java tool? Well..kinda sorta (build server)... what kind of server-side java stuff. XML.apache.org has a few well-defined products with the main one being Cocoon. This may change slightly as the web services thing comes to a head (as the speaker coordinator for my JUG www.trijug.org I can tell you this is coming to a head) and more web-servicey things happen with XML rather than publishing (Cocoon) and maybe at that time there should be a webservices.apache.org (and webservices will expand beyond XML), but for the moment you've got real products and a unity-of-purpose. (Which parts of POI fit well into..the cocoon 2 serializers for instance and others do not) So what do most people (users) come to Jakarta for? Tomcat. Why? Go to the front page. A big rattled on list of componentsIf I don't know what I'm looking for suffice to say I won't find it. If I say Tomcat the general IT population knows what I'm talking about. (and the rest know what I mean if I say the successor to JServ) Here's my 2c worth (and unless asked its the only thing I'll contribute to this discussion): Defined unity of purpose: sever side java is now too fuzzy of a mission...what are your products and categorize them: application server (tomcat) build and development tools (ant/log4j/etc) document management and publishing (lucene, POI, etc) application frameworks (avalon, struts) The Apache brand is worth a lot. You say Linux in a corporate environment you get a dirty look (once upon a time we just said Solaris-clone and installed linux to avoid political battles ;-) ), you say Apache you get a less dirty look. (You're still a radical but IBM and Sun said you're an okay radical). Jakarta needs to do some actual PROJECT work. Go in and pull these disparate components into distributions (Redhat doesn't point you to their website to download X, and then GLIB and go try and put it together yourself...not that Jakarta should be redhat, but the point being having distributions). This helps create unity of purpose as things start going into distributions and distributions generate requirements and needs which roll into features. I think this equation misses the important second order affects of collaboration. My feeling is that communities need a critical mass, as do meta-communities. I'm not sure what that size is, but in my mind the XML project has not reached it. And it is not just size that is the issue, it is the presence (or lack) of people who cross pollinate ideas. Within Jakarta, this is being done on an ever increasing scale. I think you need to have points. Both to discussions and to work. In the POI project. Try this: submit to the poi-devel list (and Marc, Ken and the lurkers may not be monitoring so the experiment would be fair) a proposal or patch to do something obviously outside of POI's mission (crack those MS file formats right open, provide apis and XML publishing utils for those formats) I bet you you'll get a unified thanks,
RE: On unity and coherence [was Re: [Request For Comment] POI @apache]
Biting the bait: Maybe you and me are following different lists Jon. AFAIK there is cooperation between Tomcat 3x and Tomcat 4x people. I sure hope we will have a Tomcat 4 at least as nice to use as 3.3 is at the moment. I am sure that most Tomcat 3.x users will upgrade as soon as they feel confident about that being the case. It is possible that many already did it. Most 3.3 supporters have no emotional attachments to either the 3.3 or the 4.x code base. Many of us just believed 3.3 was the shortest path to a production quality Tomcat. _Maybe_ there was more people with other interests on the 4.x side. Either way, the main focus is on 4.x now and I do not see any ongoing flame wars on the Tomcat lists. Everybody wants its success. IMO it is better to stop feeding the flaming and let it die. Have fun, Paulo Gaspar -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 12:37 AM To: [EMAIL PROTECTED] Subject: Re: On unity and coherence [was Re: [Request For Comment] POI @apache] on 1/5/02 3:02 PM, Sam Ruby [EMAIL PROTECTED] wrote: Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and Crimson. The developers *are* working together. I won't pretend that everything is 100% smooth sailing, but significant progress is being made. Yea...just like Tomcat 3x and Tomcat 4x...suuueee... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: On unity and coherence [was Re: [Request For Comment] POI @apache]
Hi Andrew, Before trying to organizize too much how Open Source development works, maybe you should consider that impositions of organization and discipline could kill the Golden Eggs Chicken. I can not express this POV better than Linus did in posts reported by this article: http://kerneltrap.org/article.php?sid=398 Any corporation organizizes things and I do not see better user understanding there. Besides, there is no such thing as an Open Source external customer. Those that contribute to it (the authors and even noisy guys like me) ARE the customers. People PAY Open Source by participating. If something is wrong FIX IT! (Ok! I confess I learned this stuff mostly from Jon.) If you do not like an Open Source product as it is, contribute (fight) to change it. If most of the project owners do not let you, FORK. At least you can learn a lot and save a lot of work. You probably know what I am talking about since POI is Open Source. For complex enough software, Winston Churchill's remarks about democracy apply quite well to Open Source as we know it by rephrasing them a bit: Open Source is the worse form of developing complex software, except all those others that have been tried. ( The original Winston Churchill quote: Many forms of Government have been tried, and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed, it has been said that democracy is the worst form of Government except all those others that have been. ) Relax and have fun, organic growing works or we wouldn't be here! Paulo Gaspar -Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 06, 2002 1:01 AM To: [EMAIL PROTECTED] Subject: Re: On unity and coherence [was Re: [Request For Comment] POI @apache] Not that I should have much of a role in this discussion but I'd like to contribute some thoughts stemming from an offline discussion I had. I think this discussion is still missing the point. There are a lot of outsider articles on what is wrong with Apache these days, most of them refer to the total disinterest (by many developers in the projects) on the market meaning what do the user's actually want. I'd say this is a component. (Please take this as somewhat of an outsider who has a lot of experience with Apache work-products) (as a symptom of this: Apache is OBVIOUSLY a better Web Server, TOMCAT is obviously a better App server of sorts, and though not a apache project JBOSS is a great enterprise serverso why is IIS gaining ground despite its overall suckiness?) The second component is an overall lack of unity-of-purpose. XML.apache.org hasn't reached a critical mass and in my opinion may never because it does have unity-of-purpose and I think that is part of why Stefano recommended I approach Jakarta first. POI has a lot to contribute to XML.apache.org but it has a lot of stuff that *would* contribute more to Jakarta's purpose if it had one. This isn't a slam, hear me out. The Apache group had a unity of purpose early on. They had a product: a webserver. Everything that Apache did had something directly to do with that product. Some things were semi-independent so subgroups seemed like the best way to handle it. Java-Apache had this unity-of-purpose: Java on Apache. Well for Java on Apache you need a mod to handle that (since everything is a mod in Apache) so you get mod-jserv, of course you have a lot of things that roll in and out of that based on serverside components for developing with your java mod. But you have unity-of-purpose. (or at least for a time) What is Jakarta's mission? server side java stuff. What is your product (look at the homepage)whoa thats a big list of subprojects... Wait is ant a server side java tool? Well..kinda sorta (build server)... what kind of server-side java stuff. XML.apache.org has a few well-defined products with the main one being Cocoon. This may change slightly as the web services thing comes to a head (as the speaker coordinator for my JUG www.trijug.org I can tell you this is coming to a head) and more web-servicey things happen with XML rather than publishing (Cocoon) and maybe at that time there should be a webservices.apache.org (and webservices will expand beyond XML), but for the moment you've got real products and a unity-of-purpose. (Which parts of POI fit well into..the cocoon 2 serializers for instance and others do not) So what do most people (users) come to Jakarta for? Tomcat. Why? Go to the front page. A big rattled on list of componentsIf I don't know what I'm looking for suffice to say I won't find it. If I say Tomcat the general IT population knows what I'm talking about. (and the rest know what I mean if I say the successor to JServ) Here's my 2c worth (and unless asked its the only thing I'll contribute to this discussion
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
Geir Magnusson Jr. wrote: It's my understanding that Apache Projects' unity of purpose is to encourage a collaborative, consensus-based development process What does that exactly mean? Perhaps Stefano's original preamble said it best http://java.apache.org/main/constitution.html Unlike other open source projects where an individual rules the project as a benevolent dictator, the Java Apache Project form is government is based on merit: everyone who deserves it get the right to vote and everyone who is able to vote participates in the ruling of the project. This kind of government helps in maintaining the project going even when core individuals leave the project or don't have enough time. The project itself is like the ancient Greek Agora idea, where everybody helps and who deserves it decide. This meritocracy allows the project to be very flexible toward people presence and allows fast and safe changes in the core group since who decides is always who is more involved and cares the most. I believe that everything else here, the projects, the subprojects, are just a means to serve the end of development by meritocracy. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: On unity and coherence [was Re: [Request For Comment] POI@apache]
On 1/5/02 7:28 PM, Ted Husted [EMAIL PROTECTED] wrote: I am not trying to be combative - I have watched this thread (and participated) with growing discomfort. I have to say that I think that bringing XML and Jakarta together might destroy the thing we are supposedly trying to 'save' (again, I don't get the problem...), namely the community that each group has. Larger isn't always better. I kinda agree with you on that. I also think we are more than ready for a POI vote, if someone were to post an actual proposal, including the list of committers. In that proposal, can it be argued why it belongs here? I have tried to sit on the fence, and I am glad Stefano will step up to champion the project, but I also think that if he scope of Jakarta is confusing now, adding a vendor-specific desktop document API (granted, with server-side uses) will add to it. There was recent talk for other clearly client projects to be added, with the same apparent quality of code and health of community - why not bundle the two as a seed for a new Apache client-focused project to be a peer to jakarta and XML and ...? If you have used any of the pure Java IDE's lately, it's clear that Java has indeed matured enough for use on the desktop, and initiatives on other client-side devices such as phones, PDA's, etc make for a very rich opportunity for Apache. Further, meta-API initiatives like Liberty which span both server and client (of all types) are clearly in Apache's interest, so I believe that a client-focused Apache project is appropriate for that reason as well. Maybe its not yet time for a vote. Let me state this again and make it very clear. POI has many users and many uses. No one I know of is using POI on the client. POI is as client-side as Tomcat is. (Tomcat is used by Netbeans a pure Java-IDE on the client!). HTML is for use on the client right? So is a library that outputs in HTML is clientside or serverside? Cocoon publishes documents that are generally read on the client right? Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html POI::HSSF reads or generates XLS files and is nearly always used on the server . OF all POI's users not one person is using it on the client. Please check out http://poi.sourceforge.net. The page describes its usage -Andy -- 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: On unity and coherence [was Re: [Request For Comment] POI @apache]
On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: On 1/5/02 7:28 PM, Ted Husted [EMAIL PROTECTED] wrote: I am not trying to be combative - I have watched this thread (and participated) with growing discomfort. I have to say that I think that bringing XML and Jakarta together might destroy the thing we are supposedly trying to 'save' (again, I don't get the problem...), namely the community that each group has. Larger isn't always better. I kinda agree with you on that. Ted didn't write that. I did. I also think we are more than ready for a POI vote, if someone were to post an actual proposal, including the list of committers. In that proposal, can it be argued why it belongs here? I have tried to sit on the fence, and I am glad Stefano will step up to champion the project, but I also think that if he scope of Jakarta is confusing now, adding a vendor-specific desktop document API (granted, with server-side uses) will add to it. There was recent talk for other clearly client projects to be added, with the same apparent quality of code and health of community - why not bundle the two as a seed for a new Apache client-focused project to be a peer to jakarta and XML and ...? If you have used any of the pure Java IDE's lately, it's clear that Java has indeed matured enough for use on the desktop, and initiatives on other client-side devices such as phones, PDA's, etc make for a very rich opportunity for Apache. Further, meta-API initiatives like Liberty which span both server and client (of all types) are clearly in Apache's interest, so I believe that a client-focused Apache project is appropriate for that reason as well. I also wrote that, not Ted. Maybe its not yet time for a vote. Let me state this again and make it very clear. POI has many users and many uses. No one I know of is using POI on the client. Maybe you have some marketing problems? :) POI is as client-side as Tomcat is. Why do you say that? It is used on the server side, and that's fantastic, but in my opinion (note that I recognize I am a complete outsider to your project who would be defined as a user) it seems client side. If I had a need for something like this (and I bet I will at some point), and I had the choice to look at either a) jakarta, the apache java server-side focused project or b) floccinoccinihilipilificator*, the apache java client-side project I would choose b), as I think of word and excel as a client-side thingy. No matter that my use is server-side... (Tomcat is used by Netbeans a pure Java-IDE on the client!). HTML is for use on the client right? Yep. But its a markup definition, not an API implementation. So is a library that outputs in HTML is clientside or serverside? Serverside generally, as the canonical model of HTML use is the web, with a clear delineation of server and client. However, it indeed has clientside uses - take for example any help system that outputs HTML within a monolithic desktop application. Conversely, I would argue that Excel is a totally client-side technology, and therefore a library that works with XLS files is clientside generally as the canonical model of Excel is on the desktop. However, it indeed has serverside uses Cocoon publishes documents that are generally read on the client right? Yes, but it's more than an API, right? (I don't know much about cocoon...) From what I read, POI is an API that accesses data in XLS files... Theres a huge difference. And Cocoon isn't part of Jakarta, is it? :) I don't necessarily think that xml.apache.org is the right place either, although I am not a member of that community in any way shape or form, so that opinion is worth the bits through which it was transmitted. I think that a client project peer to jakarta is still the right place, at least worth discussing, as we have the interesting temporal convergence of the proposal of multiple client side projects when java on the client side is becoming a much more interesting space to work. Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html I will. POI::HSSF reads or generates XLS files and is nearly always used on the server . OF all POI's users not one person is using it on the client. Please check out http://poi.sourceforge.net. The page describes its usage I will. Note I spent years supporting Excel 'stuff' in the financial industry as part of a project I led, and every user I knew was client-side. You may just be ahead of your time :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy -
Re: On unity and coherence [was Re: [Request For Comment] POI @apache]
Playing Devil's advocate. I think it's fair to push back on adding things to Jakarta... On 1/5/02 9:53 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Please read these posts and then tell me where you're not clear? http://www.mail-archive.com/general%40jakarta.apache.org/msg02681.html Isn't it fair to guess that the majority of your server side use would be reading documents for presentation, indexing, searching? However, you point out in the above link that the thing that makes POI special is it's ability to *write*? What's the % of mainly writing to mainly reading on the serverside? http://www.mail-archive.com/general%40jakarta.apache.org/msg02685.html Paulo might use VB to make a client side app, but I wouldn't if I wanted portability, especially if I was looking to the handheld or embedded application that could access a document remotely... http://www.mail-archive.com/general%40jakarta.apache.org/msg02690.html No comment, as it's an agreeable followup to the above. -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting We will be judged not by the monuments we build, but by the monuments we destroy - Ada Louise Huxtable -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Request For Comment] POI @ apache
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 3:16 PM ... Under the hood, I imagine that POI has more in common with things like FOP than things like Lucene. I fail to understand why you assume this. Why? I do not see POI making the generation of Word documents by FOP that much easier (it just takes care of a small bit of a very long path) but I see it taking care of most of the work of indexing Word and Excel documents with Lucene. Of course that maybe the Lucene guys do not want to support the indexing of specific document formats... Have fun, Paulo Gaspar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
on 1/4/02 9:14 AM, Scott Sanders [EMAIL PROTECTED] wrote: I can agree with Paulo, POI is about generating/reading documents with a particular foramt, and that is very useful to jakarta and xml. I believe that if it came to Apache, if would belong under Jakarta, being a Java tool, and more specifically under commons, as it is just a component to be used with other products (ie Lucene) to gain functionality in context. Scott Sanders I still don't see the point for bringing it to Jakarta. I think it is fine where it is. They have good hosting, strong leadership, etc... I'm not interested in bringing new projects into Jakarta when we are as fucked up as we are today. It is utter anarchy here and I don't think that is good. People can't even follow the rules we have *defined*. People, it isn't about code standards, that is just the symptom of the larger problem. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
Jon Stevens wrote: I'm not interested in bringing new projects into Jakarta when we are as fucked up as we are today. It is utter anarchy here and I don't think that is good. People can't even follow the rules we have *defined*. People, it isn't about code standards, that is just the symptom of the larger problem. People not following the coding standards clearly is a bug. The correct fix is likely to be to reword the guidelines to make it clear that they are, well, guidelines. And perhaps to add working to encourage subprojects to not only define standards, but also to explore viable ways to enforce them. Who knows, if somebody comes up with such a scheme (and I already outlined what type of mechanism I would find acceptable), then perhaps we would consider adopting it project wide. OK, so cast in product terms and continuing the bug analogy. Given the proposed fix above, I would not consider it a stop ship issue. In terms of where I have chosen to invest my Apache related hours, I've made it clear what types of issues I view as affecting the communities health. So we've established that we've got a bug. What should we do about it? 1) Perhaps we need to use the bug tracking system for PMC issues. That would be a welcome improvement. Anybody care to take this one? 2) Related to POI. As long as they know the current state of Jakarta and can make an informed decision, and meet all the criteria described in http://jakarta.apache.org/site/newproject.html, then they have my +1. After all, what good is it to have published criteria which omits important details like Jon will block if he feels that Jakarta is fucked up today? ;-) Oh, and Stefano's stewardship more than sufficiently meets that particular criteria in my book. 3) Related to bugs in general. They happen. Given that this is an all volunteer organization, perhaps more people should read http://jakarta.apache.org/site/understandingopensource.html . My feeling is the sentiments that are expressed there apply equally well to the organization as a whole as they do to the status of any particular code base. - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
Sam Ruby wrote: 1) Perhaps we need to use the bug tracking system for PMC issues. That would be a welcome improvement. Anybody care to take this one? Makes sense to me -- Can we list it as PMC/Site2 ? Do I have karma to add this to bugzilla myself? -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
on 1/4/02 12:00 PM, Sam Ruby [EMAIL PROTECTED] wrote: 2) Related to POI. As long as they know the current state of Jakarta and can make an informed decision, and meet all the criteria described in http://jakarta.apache.org/site/newproject.html, then they have my +1. After all, what good is it to have published criteria which omits important details like Jon will block if he feels that Jakarta is fucked up today? ;-) Sam...not even funny... I never gave a vote so don't put words into my mouth. Oh, and Stefano's stewardship more than sufficiently meets that particular criteria in my book. Yea, after I wrangled it out of him. This whole fucked mess would have been averted if Stefano had simply stepped up and said he would take stewardship. Multiple times, I said that that was needed and it *finally* got stated by him. So, shall another ballot be cast based on the latest information? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
on 1/4/02 4:14 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: That makes me wonder about the real causes of this whole fucking mess and jakarta is fucked up today feelings of yours... Of course. I forgot. I'm always wrong. Sorry. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
On Thu, 3 Jan 2002 01:13, Andrew C. Oliver wrote: I'm writing, at the recommendation of Stefano Mazzocchi, in hopes of drawing discussion and perhaps later a vote on the creation of a new Jakarta subproject based on the POI project (http://poi.sourceforge.net http://sourcefoge.net/projects/poi). The POI project consists of an API for reading and writing Microsoft's OLE2 Compound Document Format, the format used in Microsoft Office for Word and Excel documents, as well as ports of file formats based on it. Currently the project is composed into the following parts: POIFS - the pure java port of OLE 2 Compound Document format and the APIs for manipulating it. HSSF - the pure java port of Microsoft's Excel 97 File format (BIFF8) which is shared by all newer version of Excel as well. HSSFSerializer - Cocoon2 Serializer for HSSF. It uses the same XML tag language as Gnumeric. [this will be donated and hosted in Cocoon] HSSFGenerator - commencing. [this will be part of Cocoon as well] HDF - commencing. A pure java port of Microsoft's Word 97 File Format which is shared by newer versions of Word as well. ...snip... Sounds like a healthy project and a useful one (especially that HSSF stuff). It could fit into jakarta but in reality you need someone who is already an active member of the jakarta (or apache) community who is willing to champion it. Preferrably someone from the PMC. It may be a good idea to prod Stefano and see if he wants the job or perhaps someone else from cocoon. -- Cheers, Pete *--* The phrase computer literate user really means the person has been hurt so many times that the scar tissue is thick enough so he no longer feels the pain. -- Alan Cooper, The Inmates are Running the Asylum *--* -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
On Thu, 3 Jan 2002 12:20, Jon Scott Stevens wrote: I'm also a bit surprised/disappointed that no other PMC members have commented...leaving me to be the one who has to say something *again*. I guess discussion about code formatting is taking up everyone's time/energy. Some of us need more time to catch up with our mail ;) -- Cheers, Pete - Clarke's Third Law: Any technology distinguishable from magic is insufficiently advanced. - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
Geir Magnusson Jr. wrote: Comments? Why is it appropriate for Jakarta? That's the missing piece for me. You said that the Cocoon community is excited about it, it could be important for data conversion in XML land... The missing piece might be that this library is general enough to be useful for other non necessarely XML-related subprojects. -- 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: [Request For Comment] POI @ apache
On 1/3/02 8:21 AM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: Comments? Why is it appropriate for Jakarta? That's the missing piece for me. You said that the Cocoon community is excited about it, it could be important for data conversion in XML land... The missing piece might be that this library is general enough to be useful for other non necessarely XML-related subprojects. Sure, but the flip side of that is it's really more of a client-ish tool, as from what I gather it's focus is desktop-software documents (MSFT). Important, and rather cool that someone did it, but not strictly serverside. Of course, Jakarta isn't strictly server-side either. geir Stafano - can you subscribe please ? :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
on 1/3/02 5:31 AM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Exactly, ignoring M$ doesn't make it go away. I would say the opposite: there are tons of companies that base their document systems on M$ software and would like to move to a more open world but they simply can't afford loosing the legacy data, so their managers decide to stick with M$ stuff. I would say that an exporting tool would rather do the opposite than encourage people to use M$ software, would encourage much more those who already use it to get away from it. Based on the ranking that it is at now, keeping the project at sourceforget clearly doesn't hurt it at all. I don't see that as a reason to move it to the ASF. I'm not part of the Jakarta PMC (even if I've been) but I am an ASF member, which is even a higher status community-wise. Please, explain why you think my community sponsoring wouldn't be enough as a warranty for your vote. You need to be willing to step up and help integrate their project into the ASF. In other words, you (or another PMC member) needs to be willing to watch over the project. Based on your past history of appearing and disappearing (and the fact that you aren't a PMC member anymore), I'm not confident that you will stick around long enough to make sure that they integrate well and play well. What happens to their project when you decide you don't feel like keeping an eye on them anymore? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
on 1/3/02 10:15 AM, Paulo Gaspar [EMAIL PROTECTED] wrote: As Andrew remarks, it goes quite well with Lucene. It opens the door to interesting synergies like: Slide + Lucene + HTML+PDF+Word+Excel = indexed repository of the most popular document formats! Have fun, Paulo Gaspar There is no reason why those synergies can't work with a project that isn't hosted at the ASF. As long as the licenses are compatible, projects should work together just fine. I don't want the outside world to get the idea that the ASF refuses to work with projects that are not within the ASF. That would just plain suck. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Request For Comment] POI @ apache
You are right. I agree 100% with what you say here. My remark is no argument. Have fun, Paulo Gaspar -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 7:35 PM on 1/3/02 10:15 AM, Paulo Gaspar [EMAIL PROTECTED] wrote: As Andrew remarks, it goes quite well with Lucene. It opens the door to interesting synergies like: Slide + Lucene + HTML+PDF+Word+Excel = indexed repository of the most popular document formats! Have fun, Paulo Gaspar There is no reason why those synergies can't work with a project that isn't hosted at the ASF. As long as the licenses are compatible, projects should work together just fine. I don't want the outside world to get the idea that the ASF refuses to work with projects that are not within the ASF. That would just plain suck. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
on 1/2/02 6:13 AM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Sorry for the repost, I realized that I'd incorrectly labeled the post a reply (re:) and thought some folks may have not seen it because of that. A quick update, POI is the #10 project on sourceforge this morning. It sounds like your project is plenty successful where it is. it makes good business sense for Apache as a whole. Luckily Apache isn't a business, it is a non-profit volunteer organization. I don't see any convincing reason to bring POI to Jakarta, unless I see that you have a Jakarta PMC member champion your cause. Stefano's recommendation to you isn't enough, he or someone else needs to be a committer and interested in working and overseeing your project. Did you read: http://jakarta.apache.org/site/newproject.html -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
It sounds like your project is plenty successful where it is. True. However, because the vision for the project involves and would benefit both directly and indirectly several existing Apache projects, I feel it would be easier to collaborate if POI was a Jakarta project. The project will of course continue to succeed regardless of that. it makes good business sense for Apache as a whole. Luckily Apache isn't a business, it is a non-profit volunteer organization. Excuse the phrasing I was attempting to be concise while getting the following point across: I see this project as potentially being of great benefit to both Jakarta developers and users. By business sense I mean to say that greater collaboration would make it possible for developers to select a Apache-based solution where they might presently have to use proprietary technologies. This could expand the user base for the projects I mentioned as well as some of the xml.apache.org projects. I don't see any convincing reason to bring POI to Jakarta, unless I see that you have a Jakarta PMC member champion your cause. Stefano's recommendation to you isn't enough, he or someone else needs to be a committer and interested in working and overseeing your project. I see. Thank you, for taking the time to consider the prospect and provide feedback. Did you read: http://jakarta.apache.org/site/newproject.html -jon Yes I did. The guidelines lay out how to propose/approve a project, they do not seem to preclude proposing that members/commiters look at the project, comment and consider a possibly supporting a proposal. My apologies if I've gone about that the wrong way. What would you suggest is the more appropriate way to do so? -Andy -- www.sourceforge.net/projects/poi - port of Excel format to java 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: [Request For Comment] POI @ apache
Please, keep me copied since I'm not currently subscribed to general@jakarta Andrew C. Oliver wrote: I don't see any convincing reason to bring POI to Jakarta, unless I see that you have a Jakarta PMC member champion your cause. Stefano's recommendation to you isn't enough, he or someone else needs to be a committer and interested in working and overseeing your project. I do. I see. Thank you, for taking the time to consider the prospect and provide feedback. Did you read: http://jakarta.apache.org/site/newproject.html -jon Yes I did. The guidelines lay out how to propose/approve a project, they do not seem to preclude proposing that members/commiters look at the project, comment and consider a possibly supporting a proposal. We initially talked about moving this code to xml.apache because I think it would give us a great technical advantage, expecially for migrating all the existing legacy data encoded in Office formats to the web. Having the ability to edit XML content directly from M$ Office is something that many of our users would *scream* to be able to do. At the same time, I suggested Andrew to talk about it here instead of xml.apache.org because importing/exporting Office formats back and forward from XML is only one of the possible uses of such a technology (indexing office formats using Lucene is another darn good example of use that currently requires big bucks commercial software!) My apologies if I've gone about that the wrong way. What would you suggest is the more appropriate way to do so? Interpreting Jon's words with the provided context as I know him, he is afraid of you guys lacking the necessary community management skills that are required in all Apache projects in order to keep the process going and probably didn't see the importance of such a codebase under the jakarta mission. Whether or not this codebase is big/strong/good/sane/future-proof enough to be a full jakarta subproject, I don't know, up to you to decide, but we have: 1) a working codebase licensed under an ASF-compatible license and willing to be donated to the ASF along with copyright and all that. 2) another Apache community (Cocoon's) *very* excited about integrating this technology 3) two very active developers (the sourceforge logs tell us about it) 4) a sponsoring ASF member (myself) willing to take care about helping bootstrapping the community. Reading the current guidelines, community-wise, I see no obstacles in the creation of such a subproject. Technically speaking, since POI is more or less a codec library (not useful by itself), it could probably be better placed under jakarta-commons. In that case, even less community requirements would be needed, even if I would still like to appear as a sponsoring member for that codebase. Sorry if this wasn't clear from the start. Comments? -- 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: [Request For Comment] POI @ apache
On 1/2/02 7:47 PM, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Please, keep me copied since I'm not currently subscribed to general@jakarta Why not ? :) Andrew C. Oliver wrote: I don't see any convincing reason to bring POI to Jakarta, unless I see that you have a Jakarta PMC member champion your cause. Stefano's recommendation to you isn't enough, he or someone else needs to be a committer and interested in working and overseeing your project. I do. I see. Thank you, for taking the time to consider the prospect and provide feedback. Did you read: http://jakarta.apache.org/site/newproject.html -jon Yes I did. The guidelines lay out how to propose/approve a project, they do not seem to preclude proposing that members/commiters look at the project, comment and consider a possibly supporting a proposal. We initially talked about moving this code to xml.apache because I think it would give us a great technical advantage, expecially for migrating all the existing legacy data encoded in Office formats to the web. Having the ability to edit XML content directly from M$ Office is something that many of our users would *scream* to be able to do. At the same time, I suggested Andrew to talk about it here instead of xml.apache.org because importing/exporting Office formats back and forward from XML is only one of the possible uses of such a technology (indexing office formats using Lucene is another darn good example of use that currently requires big bucks commercial software!) So why not to XML.apache? My apologies if I've gone about that the wrong way. What would you suggest is the more appropriate way to do so? Interpreting Jon's words with the provided context as I know him, he is afraid of you guys lacking the necessary community management skills that are required in all Apache projects in order to keep the process going and probably didn't see the importance of such a codebase under the jakarta mission. Whether or not this codebase is big/strong/good/sane/future-proof enough to be a full jakarta subproject, I don't know, up to you to decide, but we have: 1) a working codebase licensed under an ASF-compatible license and willing to be donated to the ASF along with copyright and all that. 2) another Apache community (Cocoon's) *very* excited about integrating this technology 3) two very active developers (the sourceforge logs tell us about it) 4) a sponsoring ASF member (myself) willing to take care about helping bootstrapping the community. Reading the current guidelines, community-wise, I see no obstacles in the creation of such a subproject. Technically speaking, since POI is more or less a codec library (not useful by itself), it could probably be better placed under jakarta-commons. In that case, even less community requirements would be needed, even if I would still like to appear as a sponsoring member for that codebase. Sorry if this wasn't clear from the start. Comments? Why is it appropriate for Jakarta? That's the missing piece for me. You said that the Cocoon community is excited about it, it could be important for data conversion in XML land... geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting He who throws mud only loses ground. - Fat Albert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Request For Comment] POI @ apache
Hi, I'm writing, at the recommendation of Stefano Mazzocchi, in hopes of drawing discussion and perhaps later a vote on the creation of a new Jakarta subproject based on the POI project (http://poi.sourceforge.net http://sourcefoge.net/projects/poi). The POI project consists of an API for reading and writing Microsoft's OLE2 Compound Document Format, the format used in Microsoft Office for Word and Excel documents, as well as ports of file formats based on it. Currently the project is composed into the following parts: POIFS - the pure java port of OLE 2 Compound Document format and the APIs for manipulating it. HSSF - the pure java port of Microsoft's Excel 97 File format (BIFF8) which is shared by all newer version of Excel as well. HSSFSerializer - Cocoon2 Serializer for HSSF. It uses the same XML tag language as Gnumeric. [this will be donated and hosted in Cocoon] HSSFGenerator - commencing. [this will be part of Cocoon as well] HDF - commencing. A pure java port of Microsoft's Word 97 File Format which is shared by newer versions of Word as well. The POI project has been in development for just over 6 months. The POI project has gained a reasonably large user base and currently has four listed developers and a few occasional contributers. On any given day it makes the front page on Sourceforge's most active projects. The POI project will attract a larger development community once the Word port begins. However, the project admins (myself and Marc) will continue to develop it until pried from our cold dead fingertips regardless of anything. We released a beta over the holidays and our 1.0 release yesterday. We started the project in order to provide the ability for Cocoon to present information directly in Office formats and wanted to donate it to Cocoon directly, but the potential benefits of POI encompass those of Cocoon or xml.apache.org and we believe that many Jakarta subprojects could potentially benefit from POI and it makes good business sense for Apache as a whole. Possible collaboration scenarios are Lucene indexing large quantities of data in .doc and .xls files, Slide doing content management in a corporate environment that necessitates DOC and XLS support, Turbine doing content delivery in DOC XLS and content editing in DOC, XLS). From a personal standpoint, its the most fun thing I've worked on in a great while. Microsoft creates great brain teasers! While I don't think the project will ever be finished (there will always be a minor enhancement or detail to be worked out), it is already very useful. Thoughts? Happy New Year, -Andy -- www.sourceforge.net/projects/poi - port of Excel format to java 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]
