Re: Jakarta Status [was Code conventions]
Jon Scott Stevens wrote: on 1/4/02 4:20 PM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: They aren't even comparable, are they? Of course not. No, I agree, I was just teasing :) http://jakarta.apache.org/velocity/dvsl/ When DVSL is integrated into Turbine's presentation layer and people are using it, the comparison will definitely be Cocoon2 vs. Turbine. Uh, cool, let me take a look... -- 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: 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: Code conventions
* Paulo Gaspar [EMAIL PROTECTED] wrote: | | It could even happen in the USA and it is quite dangerous to think | otherwise (because then you are not alert). Well, I would argue that it is happening in the US now with the new military courts. -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ -- 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: More abuse of coding styles...
On Sun, 6 Jan 2002 11:26, Steve Downey wrote: Your javac has a configuration setting for the class names of inner classes? Although the inner classes use a $ embedded, rather than as a lead character. It's a similar issue. And whats that got to do with the price of fish? $ is not valid in identifiers in java language (but fine in .class file format). The recommendation in C that _ is reserved for the implementor is not a linker issue, but more of a namespace scoping issue. errr go have a look at the evolution of c/linkers and the pains some people went through re different linker/header file combos. There isn't a good way of marking a function as to be used by the implementor or the compiler, in such a way that a programmer can not conflict with it. Java has private which accomplishes that. private is an access marker - it does not define any metatype. Java has a crap metadata infrastructure - thats one of the things that C# did far better than java. Its a feature people have been asking for since 1.0 days but sun keeps dropping the ball or implementing workarounds. But reserving some characters for the implementors is not really a bad thing. Sure it is - it makes it acceptable for them to write poor code. -- Cheers, Pete The perfect way is only difficult for those who pick and choose. Do not like, do not dislike; all will then be clear. Make a hairbreadth difference and heaven and earth are set apart; if you want the truth to stand clear before you, never be for or against. - Bruce Lee -- 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: More abuse of coding styles...
-Original Message-
From: Peter Donald [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 05, 2002 9:53 PM
To: Jakarta General List
Subject: Re: More abuse of coding styles...
On Sun, 6 Jan 2002 11:26, Steve Downey wrote:
Your javac has a configuration setting for the class names of inner
classes? Although the inner classes use a $ embedded,
rather than as a lead
character. It's a similar issue.
And whats that got to do with the price of fish? $ is not valid in
identifiers in java language (but fine in .class file format).
$ is a perfectly fine character in a java identifier. Even as the initial
character. That's why it's specifically mentioned in the sun coding style
guide. It's legal, but not meant for use by all.
IOW:
class $ {
public int $() {
int $ = 5;
return $;
}
static public void main(String args[]) {
$ dollar = new $();
System.out.println(dollar.$());
}
}
is legal. Ugly as hell. But legal.
The recommendation in C that _ is reserved for the
implementor is not a
linker issue, but more of a namespace scoping issue.
errr go have a look at the evolution of c/linkers and
the pains some
people went through re different linker/header file combos.
Been there, done that, have burn marks. The identifier name space starting
with _ is reserved for implementors to provide such things as library
functions with external linkage, used by the rest of the library, without
running into conflicts with user declarations. The compiler is even entitled
to emit calls to these functions, or reference these variables, without your
direction. So if you name variables or functions things like _alloc, or
_err, and your program crashes and burns, you've got no one to blame but
yourself.
There isn't a good way
of marking a function as to be used by the implementor or
the compiler, in
such a way that a programmer can not conflict with it. Java
has private
which accomplishes that.
private is an access marker - it does not define any
metatype. Java has a
crap metadata infrastructure - thats one of the things that
C# did far better
than java. Its a feature people have been asking for since
1.0 days but sun
keeps dropping the ball or implementing workarounds.
But reserving some characters for the implementors is not
really a bad
thing.
Sure it is - it makes it acceptable for them to write poor code.
In what way does it make it acceptable for them to write poor code? For
example, the JSP spec reserves _jsp, jsp, _jspx and jspx for identifiers
used in the classes generated by the page compiler. What other way do you
propose to guarantee that the compiler won't generate names that conflict
with ones I declare in a page?
-SMD
This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named. Any use, copying or disclosure by any other person is strictly
prohibited. If you have received this transmission in error, please notify
the sender via e-mail.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
On 1/5/02 11:22 PM, Steve Downey [EMAIL PROTECTED] wrote: In what way does it make it acceptable for them to write poor code? For example, the JSP spec reserves _jsp, jsp, _jspx and jspx for identifiers used in the classes generated by the page compiler. What other way do you propose to guarantee that the compiler won't generate names that conflict with ones I declare in a page? As a SWAG, I would think you could parse out the ones you declare, keep a list, and ensure you don't generate anything that conflicts? -- 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]
Cultural homogeneity
I was leafing through my copy of A Pattern Language by Alexander, Ishikawa and Silverstein, which is really about architecture of human habitat (buildings and environs), and ran across some interesting assertions about society and groups. I haven't read the book end to end, as I just pick it up and read bits and pieces, but I am generally struck by the validity of the basic insights expressed. I thought I would share, as my thinking about removing community containers here in Jakarta, XML et al resonates well this. There is nothing which says the following is any more valid than any other point of view expressed here, so this shouldn't be read as an appeal to some kind of 'authority' (like we *never* do that here...) - just interesting as it comes from another intellectual discipline studying the exact problems we are trying to grapple with. The summary for me is that I think that the Apache sub communities are valuable, and should be kept. The homogeneous and undifferentiated character of modern cities kills all varieties of life styles and arrests the growth of individual character. (p43) Kind of general as the assertion, the text then talks about three kinds of structure, heterogeneous (bland and conformist), ghetto (organized by economic or physical characteristics, traps and isolates groups), and mosaic of subcultures, the latter being the preference, with the conclusion : Do everything possible to enrich the cultures and subcultures of the city, by breaking the city, as far as possible, into a vast mosaic of small and different subcultures, each with it's own spatial territory, and each with the power to create it's own distinct life style. Make sure that the subcultures are small enough so that each person has access to the full variety of life styles in the subcultures near his own. I think the notion of power to create it's own distinct lifestyle is the important aspect that applies to the issue of disbanding the community boundaries distinguishing XML and Jakarta. Individuals have no effective voice in any community of more than 5,000 - 10,000 persons (p 71) While I don't think that the quantitative values are important, I think the fundamental idea is sound - in order for individual voices to be heard, the group has to be small enough. The conclusion : Decentralize city governments in a way that gives local control to communities [...]. As nearly as possible, use natural geographic and historical boundaries to mark those communities. Give each community the power to initiate, decide and execute the affairs that concern it closely. I think I don't need to explain how this applies to us :) There's more, but I'm beat. Happy weekend. :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Be a giant. Take giant steps. Do giant things... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
