RE: More abuse of coding styles...
Stephane Bailliez typed the following on 09:42 AM 1/4/2002 +
We had that discussion once on Commons, and many people liked the
underscore convention.
I can understand why:
public void setSomething(Object something){
something = something;
}
It is one of my major source of error when not using the '_' and I have seen
the error several times along with variable naming gymnastics to avoid the
this. people would use aSomething or theSomething or whatever. That look
crappy in the Javadoc.
The standard way to handle this is of course:
public void setSomething(Object something){
this.something = something;
}
Kief
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: More abuse of coding styles...
-Original Message- From: Kief Morris [mailto:[EMAIL PROTECTED]] It is one of my major source of error when not using the '_' and I have seen the error several times along with variable naming gymnastics to avoid the this. people would use aSomething or ^ theSomething or whatever. That look crappy in the Javadoc. The standard way to handle this is of course: [...] See above. People will often forget to type 'this.' for the same reason they forget to put braces around a single line statement: lazyness. I think we all do this from time to time...human nature you know... Stephane -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
On 1/4/02 3:48 AM, Endre Stølsvik [EMAIL PROTECTED] wrote:
On Thu, 3 Jan 2002, Jon Scott Stevens wrote:
| It is amazing to me...with all the discussion about coding styles and
| following them, we still have people committing code that doesn't follow
| what rules we do have...
|
| on 1/3/02 11:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
|
| Re: cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging
| SimpleLog.java
|
| +if(_showtime) {
|
| http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367
|
| Variable names should not start with underscore _ or dollar sign $
| characters, even though both are allowed.
The _instanceVariable and also the __staticVariable idea makes real good
sense to me nowadays. Do you have any arguments against it? (btw; this is
a genuine question!)..
I used to do that all the time in C++ developent, although I put it at the
end
membervar_
It really helps, I think.
And while talking about code conventions; people writing like this:
if (something)
{
}
should be shot right there on the spot, in the act of typing it.
The ONLY way to write blocks is like this:
if (something) {
}
;)
You left out my 'favorite'
if ( something ) { }
:)
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Now what do we do?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote: Let's all take a moment to review: http://www.godwinslaw.com/ Amusing but not very pertinent to the discussion. No one exchanged accusations of Nazism. Although I recognize that your goal was probably to diffuse the tension. As things stand today, the Jakarta project is a loose assembly of subprojects united by a common license, a common web site and a common PMC. Here is what http://jakarta.apache.org/site/roles.html has to say on the Project Management Committee (PMC): This committee is the official managing body of the Jakarta Project and is responsible for setting overall project direction. The PMC currently follows a non-interventionist policy. Its actions in the past year have been limited to accepting or rejecting new subprojects which is inadequate for setting the overall project direction, the stated goal of the PMC. The inability of the PMC to take initiative stems from the Apache voting process where every member has a veto power. This limits the decision power of the PMC to consensual decisions only. The Jakarta PMC is averse of discussing things in private in fear that its legitimacy might be challenged. IMHO, if the legitimacy of the PMC is challenged, let the challenger wait and suffer until the next PMC elections. I believe the next elections are scheduled for February or March 2002. The current system of veto based voting might be appropriate for development but is inappropriate for managing large projects like Jakarta. Either we admit it and act now or watch Jakarta become SourceForge-elite, an assembly of excellent projects but with no common purpose. Jakarta does not have a benevolent dictator where the puck stops. Recognizing this fact, we either: 1) Elect a PMC with real power, power to intervene and take painful decisions, until the next elections. 2) Instate a system based on referendum, where the public can directly intervene in making laws. By public, I mean developers with commit rights. To avoid voting on trivialities, a referendum would require the support of at least five committers to acquire the valid status. After a possible but short delay, a valid referendum is submitted to popular vote. The result of the vote determines whether the referendum is accepted or rejected. An accepted referendum becomes law of the land. To avoid keeping voting on the same issue time and again, a wait period of 12 months is necessary between two referenda on the same or nearly the same issue. 3) Keeps things as they are and hope for the best. Regards, Ceki -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: More abuse of coding styles...
At 10:44 04.01.2002 +, you wrote:
-Original Message-
From: Kief Morris [mailto:[EMAIL PROTECTED]]
It is one of my major source of error when not using the '_' and I
have seen the error several times along with variable naming
gymnastics to avoid the this. people would use aSomething or
^
theSomething or whatever. That look crappy in the Javadoc.
The standard way to handle this is of course:
[...]
See above. People will often forget to type 'this.' for the same reason they
forget to put braces around a single line statement: lazyness.
I think we all do this from time to time...human nature you know...
Stephane
People who repeatedly forget to type this represent a minority and
should perhaps look to exercise a different profession. The problem
with
public void setSomething(Object something){
this.something = something;
}
is
public void setSomethingComplicated(Object sometingComplicateed){
this.somethingComplicated = somethingComplicated;
}
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
Hey Jon,
It is not amazing. It is normal. The paragraph that you quoted says:
All Java Language source code in the repository must be written in
conformance to the Code Conventions for the Java Programming Language
as published by Sun. However, some projects may decide to override
these defaults and use their own defined conventions. For example, the
Turbine project has its own defined conventions which are similar to
the Sun standards but specify slightly different conventions.
Which really reads: we have conventions but you are free to ignore
them -- what people have flocked to do gleefully..
Cheers, Ceki
At 17:54 03.01.2002 -0800, you wrote:
It is amazing to me...with all the discussion about coding styles and
following them, we still have people committing code that doesn't follow
what rules we do have...
on 1/3/02 11:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Re: cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging
SimpleLog.java
+if(_showtime) {
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367
Variable names should not start with underscore _ or dollar sign $
characters, even though both are allowed.
http://jakarta.apache.org/site/source.html
All Java Language source code in the repository must be written in
conformance to the Code Conventions for the Java Programming Language as
published by Sun.
-jon
--
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: More abuse of coding styles...
As a point of order:
The use of this is recommended by the Elements of Java Style, which is
cited in the Commons charter.
Though, I have myself been victimized by the trap Ceki mentions.
-Ted.
Ceki Gülcü wrote:
People who repeatedly forget to type this represent a minority and
should perhaps look to exercise a different profession. The problem
with
public void setSomething(Object something){
this.something = something;
}
is
public void setSomethingComplicated(Object sometingComplicateed){
this.somethingComplicated = somethingComplicated;
}
--
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
If some particular codebase under the Jakarta umbrella consistently
chose to take actions which were inconsistent with the Apache mission,
then I'm confident that the PMC would swiftly act to disolve this code
base. I am not aware of this being done before, so it would be
uncharted territory, but I'm sure we would find a way. And that way
would not require 100% consensus.
In my mind, the willful insertion of newlines in direct contradiction
to the Code Conventions for the Java Programming Language does not
rise to this level.
This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.
Is this how we want Jakarta to be? If not, what can be done?
I don't see what the negative consequences for community are when I do
something like
if ( condition )
{
statement;
}
versus
if ( condition ) {
statement;
}
or
if ( condition )
statement;
Other than I made my code is more readable :)
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world? We are going to
look like a bunch of PHB's if we do this. Someone's is then going to write
the utility JU (Jakarta Uglifier).
I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community. Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.
Aside : does Sun use deviation from coding standards as an actionable HR
issue? ;)
On your resume, I see that you were terminated for cause at Sun?
Yes, I created too many classes with the opening brace on a separate
line...
--
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: Code conventions
Geir Magnusson Jr. wrote: For those of us (like me) that don¹t get it, can we do a quick review why deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is such a threat to the ongoing health of Jakarta? And if the above isn't really the problem, but just an example, can we talk a bit about what the problems are? I believe it is reasonable to expect that a given codebase will follow a common convention. This is especially important in a ASF product, since we expect that the product will maintained over a long period of time by many different individuals. I fully support the idea that each codebase is entitled to its own conventions. I also fully support the idea that having defined conventions, we should follow them. I think the status quo is just fine, but we do have to remember to watch each other's backs, and remind people to use the conventions expected within each codebase. -- 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: More abuse of coding styles...
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
[...]
People who repeatedly forget to type this represent a minority and
should perhaps look to exercise a different profession. The problem
You are right, but I think you know perfectly what kind of horrors you can
find in most code out there and there is still shortage of 'developpers'.
Let's face it the code quality in Jakarta is extremely high compared with
what I have seen in the industry, the most horrible I have seen in my
limited experience being in the Defense and/or aeronautical industry. I was
beginning my career at this time and could not believe someone could come up
with sleep() to synchronize work between threads and complain that the OS
was buggy since it was 'working' differently on different computers...
with
[..]
public void setSomethingComplicated(Object sometingComplicateed){
this.somethingComplicated = somethingComplicated;
}
right.. I forgot the best one...I have been hit by this as well..
Stephane
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: proposal for the jakarta startpage
Jon Scott Stevens [EMAIL PROTECTED] wrote: http://www.apache.org/foundation/projects.html I'm nobody at ASF but I am on this mailling list. I think it's my first post (or near). I just wanna say: Jon, It's a really good job! -- Arnaud, STE-Formations Informatiques, fapse, ULg, .BE -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 7:23 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: At 06:46 04.01.2002 -0500, you wrote: On 1/4/02 6:04 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: Jakarta does not have a benevolent dictator where the puck stops. Recognizing this fact, we either: [SNIP] 3) Keeps things as they are and hope for the best. For those of us (like me) that don¹t get it, can we do a quick review why deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is such a threat to the ongoing health of Jakarta? And if the above isn't really the problem, but just an example, can we talk a bit about what the problems are? Deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is *not* a threat to the ongoing health of Jakarta. It is just an example, albeit a symbolic one. Whew ;) The threat is to Jakarta's *nature* and it comes from our indecisiveness. Real problems I see is 1) lack of focus, I too worry about this. A lot. I don't know what to do about it yet. 2) duplication between projects, Too many damn loggers - thank goodness sun is providing us with on via JSR-47. I am sure that the Code Conventions will be followed to the letter too. (You know I'm kidding - I'm a huge log4j fan, but that one was *just* too easy...) Seriously, I don't know if that is a problem, as I think it drives development. We have two web frameworks, Turbine and Struts, and they are different in current implementation, and as far as I understand it, different in evolutionary roadmap. I think this is good and healthy. We have regexp and ORO. I always use ORO for the Perl stuff. No other comments. We have repetition in commons/commons-sandbox, which I think is great. Those are the top level ones. It's clear that there is repetition within projects (the database connection pools being my canonical example) but that too seems to be evidence of exploring the solution space rather than pure wheel re-invention (although there is some of that...) I think (and only 'I thin') the only thing we can do about this, as you can't mandate what project communities decide to work on, is to ensure that the top level projects remain clear in scope, and encourage cross-project cooperation and sharing, which I think the Commons was intended in part to do. 3) lack of common procedures for doing things. Mixed feelings, as this tends to be personal taste, and leads to operational totalitarianism which I think stifles innovation. There is something to be said for common build procedures, but with ant and a little documentation, it generally isn't a big deal I've found. Are these perceived as problems by others or is it just my imagination? -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 06:57 04.01.2002 -0500, you wrote:
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
If some particular codebase under the Jakarta umbrella consistently
chose to take actions which were inconsistent with the Apache mission,
then I'm confident that the PMC would swiftly act to disolve this code
base. I am not aware of this being done before, so it would be
uncharted territory, but I'm sure we would find a way. And that way
would not require 100% consensus.
In my mind, the willful insertion of newlines in direct contradiction
to the Code Conventions for the Java Programming Language does not
rise to this level.
This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.
Is this how we want Jakarta to be? If not, what can be done?
I don't see what the negative consequences for community are when I do
something like
if ( condition )
{
statement;
}
versus
if ( condition ) {
statement;
}
or
if ( condition )
statement;
Other than I made my code is more readable :)
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world? We are going to
look like a bunch of PHB's if we do this. Someone's is then going to write
the utility JU (Jakarta Uglifier).
I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community. Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.
All excellent points. I don't have any good answers, just more
questions.
Yes, by imposing strict code conventions there is a real danger of
acting like a PHB. Yes, code conventions infringe on artistic freedom
and might even curtail creativity.
The debate about code conventions is just an excuse to ask the
following question, and it is a question:
Do we want to instate rules for the good of the larger community?
We keep saying that Jakarta is not SourceForge. How can this be if
each project can act totally independently?
Aside : does Sun use deviation from coding standards as an actionable HR
issue? ;)
On your resume, I see that you were terminated for cause at Sun?
Yes, I created too many classes with the opening brace on a separate
line...
Remember the scene where Lisa, from the Simpons, is thrown out of
music class even of she plays her sax beautifully. We all emphasize
with Lisa's view. However, what would you do if you were in the
teacher's shoes?
Questions, questions...
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On 1/4/02 7:56 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
At 06:57 04.01.2002 -0500, you wrote:
On 1/4/02 6:43 AM, Ceki Gülcü [EMAIL PROTECTED] wrote:
On Wed, 02 Jan 2002 06:03:43 -0800, Sam Ruby wrote:
If some particular codebase under the Jakarta umbrella consistently
chose to take actions which were inconsistent with the Apache mission,
then I'm confident that the PMC would swiftly act to disolve this code
base. I am not aware of this being done before, so it would be
uncharted territory, but I'm sure we would find a way. And that way
would not require 100% consensus.
In my mind, the willful insertion of newlines in direct contradiction
to the Code Conventions for the Java Programming Language does not
rise to this level.
This analysis sums up the current state of affairs. As long as you are
in and do not commit murder, you are free to do whatever you like,
regardless of the consequences of your actions. Murder is defined as
not adopting or infringing on the Apache Software License.
Is this how we want Jakarta to be? If not, what can be done?
I don't see what the negative consequences for community are when I do
something like
if ( condition )
{
statement;
}
versus
if ( condition ) {
statement;
}
or
if ( condition )
statement;
Other than I made my code is more readable :)
My question is what are the consequences to forcing me to do #2 when #1 is
perfectly acceptable throughout the professional world? We are going to
look like a bunch of PHB's if we do this. Someone's is then going to write
the utility JU (Jakarta Uglifier).
I realize that some of this is simply a matter of taste, and people don't
think that #1 above is more readable than #2. I'm just trying to figure out
why this personal style decision in what is in many ways an artistic
endevour constitutes a risk to the community. Note that I don't advocate a
coding free for all - I also understand that with multiple developers, some
'workmanlike' ('workpersonlike'?) standards are important.
All excellent points. I don't have any good answers, just more
questions.
Yes, by imposing strict code conventions there is a real danger of
acting like a PHB. Yes, code conventions infringe on artistic freedom
and might even curtail creativity.
The debate about code conventions is just an excuse to ask the
following question, and it is a question:
Do we want to instate rules for the good of the larger community?
I think yes, but the prepositional phrase for the good of the larger
community is going to be the trouble spot... Historically always has :)
We keep saying that Jakarta is not SourceForge. How can this be if
each project can act totally independently?
Because they really can't act *totally* independently, additional projects
can't be formed (and abandoned) ad hoc by 'outsiders', there is indeed peer
pressure (as well mechanical things like Gump) that enforce some
consistency, and lots of cross pollenation. I mean, Jon is everywhere ;)
From my personal experience, I do think of it as one big community but
different 'departments'. I talk to people from many of the subprojects when
I need something or have a question, and I certainly feel welcome and like
it's one big group.
Another thought I have on this is that we are sort of like sourdough bread
made with a starter :) We add new projects, but it's (usually) initiated,
championed and/or participated in by someone steeped in the Apache/Jakarta
'gestalt', so the traditions and practices continue.
Aside : does Sun use deviation from coding standards as an actionable HR
issue? ;)
On your resume, I see that you were terminated for cause at Sun?
Yes, I created too many classes with the opening brace on a separate
line...
Remember the scene where Lisa, from the Simpons, is thrown out of
music class even of she plays her sax beautifully. We all emphasize
with Lisa's view. However, what would you do if you were in the
teacher's shoes?
(I thought you were going to the scene : Lisa, get away from that Jazz
man! )
Well, that's the difference between the teacher having to do something about
it, and Principal Skinner listening in over the intercom and getting Lisa to
leave Within the community, the community is the teacher, and can
legislate itself (modulo Principal Skinner, of course...)
Questions, questions...
:)
--
Ceki Gülcü - http://qos.ch
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Now what do we do?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Fri, 4 Jan 2002 23:07, Ted Husted wrote: Geir Magnusson Jr. wrote: For those of us (like me) that dont get it, can we do a quick review why deviation from the One True But Sometimes Really Ugly Coding Standard as defined by Sun Microsystems is such a threat to the ongoing health of Jakarta? And if the above isn't really the problem, but just an example, can we talk a bit about what the problems are? I believe it is reasonable to expect that a given codebase will follow a common convention. This is especially important in a ASF product, since we expect that the product will maintained over a long period of time by many different individuals. I fully support the idea that each codebase is entitled to its own conventions. I also fully support the idea that having defined conventions, we should follow them. I think the status quo is just fine, but we do have to remember to watch each other's backs, and remind people to use the conventions expected within each codebase. Thats nice for some codebases but not appropriate for all. For instance the Ant codebase has got to have at least 10-15 different styles (probably way way way more) because 70% of code is not written by the committers but by members of community who have their own particular tastes. It is is largely up to the committers to decide whether to restyle the files and that really has not greatly impacted the quality of ant. However other codebases have much more rigourous conventions that are followed precisely. Its up to the developers what they want to do. -- Cheers, Pete --- It is easy to dodge our responsibilities, but we cannot dodge the consequences of dodging our responsibilities. -Josiah Stamp --- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
On Fri, 4 Jan 2002 22:04, Ceki Gülcü wrote: 1) Elect a PMC with real power, power to intervene and take painful decisions, until the next elections. -1 power would be abused and misused. If power is what you want you are not going to get it by donning a skippy badge but earning it through respect. 2) Instate a system based on referendum, where the public can directly intervene in making laws. By public, I mean developers with commit rights. yay - popularity contests! That would be sooo much fun. To avoid keeping voting on the same issue time and again, a wait period of 12 months is necessary between two referenda on the same or nearly the same issue. And maybe we should elect a committee to determine whether issues are too similar and they can break apart into sub-committees to determine the viability of holding a referendum to determine if two issues are dissimilar enough that another referendum could be held for the issue. 3) Keeps things as they are and hope for the best. things as they are are for the best. People do things because they see that it is the right thing to do for them - which usually means it is technically the right thing. Sometimes it takes time (it took me 1.5 years to convince one apache person of something) but most things work out better in the end. At times it is infuriating when someone else is doing something stupid but forcing them to change is not the answer - for one you may be wrong, if not you are probably going to cause resentment - not something healthy for the community. -- Cheers, Pete - First, we shape our tools, thereafter, they shape us. - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
Peter Donald wrote: Thats nice for some codebases but not appropriate for all. For instance the Ant codebase has got to have at least 10-15 different styles (probably way way way more) because 70% of code is not written by the committers but by members of community who have their own particular tastes. It is is largely up to the committers to decide whether to restyle the files and that really has not greatly impacted the quality of ant. However other codebases have much more rigourous conventions that are followed precisely. Its up to the developers what they want to do. Agreed. I'm simply saying that, moving forward, the Ant PMC member should encourage the subproject to stick to the default convention, or declare one of their own. If we had been more careful about this sooner, then perhaps the Ant codebase would not be host to so many diverse styles. I agree that any change has to be made by a Committer to the subproject, but reserve our right to nag. If the Committers want to ignore us they can, but that doesn't mean we should go quietly into the night. I personally believe these things don't happen because people are bloody-minded, they happen because people are unaware, and we haven't been watching each other's back. In the meantime, I do suggest we go with rule #1 - Adhere to the style of the original. -- 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: Code conventions
At 08:01 04.01.2002 -0500, Geir Magnusson Jr. wrote: The debate about code conventions is just an excuse to ask the following question, and it is a question: Do we want to instate rules for the good of the larger community? I think yes, but the prepositional phrase for the good of the larger community is going to be the trouble spot... Historically always has :) We keep saying that Jakarta is not SourceForge. How can this be if each project can act totally independently? Because they really can't act *totally* independently, additional projects can't be formed (and abandoned) ad hoc by 'outsiders', there is indeed peer pressure (as well mechanical things like Gump) that enforce some consistency, and lots of cross pollenation. I mean, Jon is everywhere ;) From my personal experience, I do think of it as one big community but different 'departments'. I talk to people from many of the subprojects when I need something or have a question, and I certainly feel welcome and like it's one big group. That's a good description. Another thought I have on this is that we are sort of like sourdough bread made with a starter :) We add new projects, but it's (usually) initiated, championed and/or participated in by someone steeped in the Apache/Jakarta 'gestalt', so the traditions and practices continue. The reasons for which projects get accepted or rejected is an important subject in itself. Remember the scene where Lisa, from the Simpons, is thrown out of music class even of she plays her sax beautifully. We all emphasize with Lisa's view. However, what would you do if you were in the teacher's shoes? (I thought you were going to the scene : Lisa, get away from that Jazz man! ) Oh, yes, then she (Maggie) turns to the to the Jazz man and says: Nothing personal, I just fear the unfamiliar. How true, how succinct. Well, that's the difference between the teacher having to do something about it, and Principal Skinner listening in over the intercom and getting Lisa to leave Within the community, the community is the teacher, and can legislate itself (modulo Principal Skinner, of course...) Amusingly enough that episode starts with Bart writing on the chalkboard: I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! I will not instigate revolution! Regards, Bart. -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 00:55 05.01.2002 +1100, you wrote: On Fri, 4 Jan 2002 22:04, Ceki Gülcü wrote: 1) Elect a PMC with real power, power to intervene and take painful decisions, until the next elections. -1 power would be abused and misused. If power is what you want you are not going to get it by donning a skippy badge but earning it through respect. Power can and is abused. Knives can and do cut through flesh. Knives can also be used to cut bread. I have no problem delegating legislative power to the members of parliament as long as its members were elected for a limited length term in fair and square elections. 2) Instate a system based on referendum, where the public can directly intervene in making laws. By public, I mean developers with commit rights. yay - popularity contests! That would be sooo much fun. Who is talking about popularity contest? What popularity contest? To avoid keeping voting on the same issue time and again, a wait period of 12 months is necessary between two referenda on the same or nearly the same issue. And maybe we should elect a committee to determine whether issues are too similar and they can break apart into sub-committees to determine the viability of holding a referendum to determine if two issues are dissimilar enough that another referendum could be held for the issue. Laugh all you want. Referenda are great. Ask any Swiss citizen. 3) Keeps things as they are and hope for the best. things as they are are for the best. People do things because they see that it is the right thing to do for them - which usually means it is technically the right thing. Sometimes it takes time (it took me 1.5 years to convince one apache person of something) but most things work out better in the end. At times it is infuriating when someone else is doing something stupid but forcing them to change is not the answer - for one you may be wrong, if not you are probably going to cause resentment - not something healthy for the community. I really don't like paying taxes but I do. I would be great to live in the Bahamas, drink cocktails and fornicate day in day out. -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 00:57 05.01.2002 +1100, you wrote: On Fri, 4 Jan 2002 23:23, Ceki Gülcü wrote: The threat is to Jakarta's *nature* and it comes from our indecisiveness. Real problems I see is 1) lack of focus, Dont see this as a problem. Each project is usually focused on its dowmain and the overall project has a sort of scope. Personally I would have no problem widening scope of jakarta to include virtually any java project, serverside, clientside, frameworks, products, etc but not everyone thinks this is a great idea ;) No, some people would not like to see Jakarta widen its scope and they would -1 any steps in that direction. However, it is certainly possible that a majority of Jakarta committers would be amenable to the idea. In the system I am suggesting, you would propose the idea, have four other committers support it, and then launch a vote on the subject. If it were adopted then the scope of Jakarta would be widened and nobody would be able to do anything about it, not me, not Ted, not even Jon. Widening the scope of Jakarta is not necessarily a bad idea. Your ideas are not all bad. (Don't get me wrong, there are not always good either.) 2) duplication between projects, diversity aids evolution though preferably it would be intra rather than inter project duplicity. However the PMC has historically not seen that as desirable due to advertising. duplicity - noun, plural duplicities 1. a. Deliberate deceptiveness in behavior or speech. b. An instance of deliberate deceptiveness; double-dealing. 2. The quality or state of being twofold or double. I have read and reread your comment. It just does not make any sense. 3) lack of common procedures for doing things. This is the one possible issue I see. However I only see it as a problem for the external interface between projects. Mainly this involves things like release naming cconventions, targets in ant files, location of intermediate and destination files in a build. It really is irrelevent to outsiders what indent style is used, whether anakia or stylebook is used yadda yadda. So I +1 on suggesting standards for external parts of project, -1 for forcing it Indeed, that seems to be the consensus. -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
Aside : does Sun use deviation from coding standards as an actionable HR issue? ;) On your resume, I see that you were terminated for cause at Sun? Yes, I created too many classes with the opening brace on a separate line... I don't know about sun, but we would certainly warn employees about repeated infringements, and that *is* the start of a process which can end in dismissal for persistently deviating from code standards. I expect the same process here could lead to a commiter being disenfranchised (what is the correct verb?) if their deviation was sufficiently persistent, what you have to hope is that we have enough intelligence to respond to the first warning. d. -- 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: Code conventions
Ceci wrote: The inability of the PMC to take initiative stems from the Apache voting process snip The current system snip is inappropriate for managing large projects like Jakarta. snip I agree with this, I've only been a commiter since the end of last summer, and have been surprised that while the web site says.. This committee is the official managing body of the Jakarta Project and is responsible for setting overall project direction. It does not appear very pro-active in this role. I've been subscribed to this list out of curiosity about what the PMC do, to keep a finger on the pulse as it were, and apart from the discussions about new projects and the current rash of opinion on code standards there seems to be little traffic discussing overall project direction Perhaps thats because the direction is not changing, are the goals of the project still the same, are the subprojects all still moving steadily forward? They seem to be, and this would be a good reason for not interfering, after all there are no deadlines except those imposed by individual projects and few imperatives of the kind which, in the commercial world, need to be enforced by PM's. we either: 1) Elect a PMC with real power, power to intervene and take painful decisions, until the next elections. In a democracy (and I *know* apache isn't that) we elect from amongst ourselves representatives whom we charge with making decisions on our behalf, for that to make any sense we have to give them the authority to make those decisons and bind ourselves to them, anything else is just posturing. 2) Instate a system based on referendum, where the public can directly intervene in making laws. By public, I mean developers with commit rights. Always contentious, referenda are un-democratic in that they imply that the fundamental assertion of democracy (that we elect people to represent us) is flawed. IMHO (as this whole spiel is) referenda would therefore render the PMC irrelevant. However consensus decisions are *much* harder to achieve in larger groups, it would be un-realistic to expect every commiter to spend time giving every vote serious consideration, and so I favour a PMC where the elected members have made a commitment to considering the issues. 3) Keeps things as they are and hope for the best. Unless the goals of the project have changed, or unless a significant change is needed to either the goals or the nature of the project the existing system should continue to work, perhaps Ceci's comments stem from a feeling that change is needed of the kind only changes in PM can accomodate. If so what's wrong? and why won't the current system be able to deliver the changes needed? d. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
Jon Scott Stevens wrote: http://jakarta.apache.org/site/source.html All Java Language source code in the repository must be written in conformance to the Code Conventions for the Java Programming Language as published by Sun. -jon Sun ? ;-) I thought it was agreed a long time ago that jakarta.apache.org != Sun and that xml.apache.org != IBM Every time I have seen a discussion about coding styles, it is never with an altruistic bent. No one ever says I should change my coding style to be more like yours. No, it is always You should change your style to be more like mine. If someone writes clean, elegant code, it doesn't really matter if it's KR style or Whitesmith's style. If we had Michaelangelo working here, I really don't think that we would care if he were using marble or alabaster, the result would be magnificent enough. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Code conventions
At 10:32 04.01.2002 -0500, you wrote: For reasons that are unknown to me, none of the e-mail that I have sent over the last few days has made it out to the mailing lists. For all I know, at some point in the distant future, it will all be unleashed and make little sense out of context. :-( Anyway, it looks like e-mail that I send now gets through so let me take advantage of it while I can... Ceki Gülcü wrote: If some particular codebase under the Jakarta umbrella consistently chose to take actions which were inconsistent with the Apache mission, then I'm confident that the PMC would swiftly act to disolve this code base. I am not aware of this being done before, so it would be uncharted territory, but I'm sure we would find a way. And that way would not require 100% consensus. In my mind, the willful insertion of newlines in direct contradiction to the Code Conventions for the Java Programming Language does not rise to this level. This analysis sums up the current state of affairs. As long as you are in and do not commit murder, you are free to do whatever you like, regardless of the consequences of your actions. Murder is defined as not adopting or infringing on the Apache Software License. All I am saying is that adopting a different set of coding conventions should not be a federal crime. I totally agree. Jakarta effectively is a federation of states, each with the power to adopt their own conventions. I do have great sympathy for Jon's point that those subprojects that have not taken the time or effort to document their standards do a great disservice to themselves and us all. Ditto. Real problems I see is 1) lack of focus, 2) duplication between projects, 3) lack of common procedures for doing things. Let me start with #2. Did you realize that the Tomcat project can service HTTP requests? Gasp! Lets get them to rip this code out as Apache has a little known HTTPD project which owns this mission. Not. I see where you are heading. This instance of duplication of effort is well known and essentially sanctioned by the board. Allowing people to fork and pursue their own vision is part of the essence what makes open source different then the centrally planned economies that one often finds in big corporate software development projects. Well put. Re: focus. What do ant and httpd have in common? The purpose of Apache is not to build a single product or family of products. The purpose is to propagate an open methodology centered around community base development. Quality or integration or unity of purpose are often useful by-products, but not the central goal. Couldn't agree more. Re: lack of common procedures. I will grant you that this is an area that we can always improve on. You have made a number of references to a benevolent dictator implying that the existence of such would be an improvement over the current state of affairs. If that is the case, then I am not that person. I prefer to educate or cajole or nag over dictating. Gump is a prime example. (Note: in the case of a federal crime mentioned above, I would not hesitate to initiate action to remove a committer or even an entire code base). Gump is a prime example indeed. Masterfully done. As an example related back to this subject line, I would not be in favor of a tool which rejects commits that don't conform to a particular style. I also would not be in favor of a tool which post-processes commits to retrofit a particular style. I would be in favor of a tool which reviews commits and informs you of issues that it determines. At the moment, Jon serves this purpose. ;-) I will not instigate revolution! I will not instigate revolution! Be forewarned that the Apache tradition is to allow people with enough fire in their belly to tackle a particular problem that is important to them the freedom to do so. If the problems you see are something that you feel need tackling and the only effective way in which this can be accomplished is for you to become the Jakarta PMC chair, then I could certainly arrange for an election to take place. I can't guarantee the results of the election or the success of your quest, but I can do my part to enable you to pursue your goals. Think about this for a while, and let me know if this is a path you wish to pursue. I have thought about for about 30 seconds and the answer is no, non, nein, nyet. Thanks, but no thanks. You don't want me as chairman. Trust me. I hope that was clear enough to dispel any misconceptions. If not, I'll be sure to repeat it again the next time the question comes up. We have been lucky to have you serve as PMC chair. I do not wish to offend anyone but I can't think of anyone else better qualified than Sam. If I were to draw list of preferences for chair my name would not be second after Sam, not the third, not the fourth... Coming back to your point of the propagation of an open methodology centered around
Re: Jakarta Status [was Code conventions]
Ted Husted wrote: What would also help, I think, would be if we published more of our statistics. I know Vincent was working on a download stats page once. I've also seen people post interesting statistics about the posts to the mailing lists. A snapshot of how many commits are being made and number of unique committers making them would also be interesting. And other things, I'm sure. Now, if I only had the faintest idea of how to automate something like this ... Stefano, I and others are working on this. http://marc.theaimsgroup.com/?l=xml-apache-generalm=100857962129228w=2 http://www.apache.org/~stefano/forrest/1.5/ - Sam Ruby P.S. Food for thought: wouldn't it be nice if we could somehow merge xml and Jakarta? Then discussions as to where POI should go would be moot. Gump doesn't care about these arbitrary distinctions, why should we? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
At 11:34 04.01.2002 -0500, you wrote: Ted Husted wrote: What would also help, I think, would be if we published more of our statistics. I know Vincent was working on a download stats page once. I've also seen people post interesting statistics about the posts to the mailing lists. A snapshot of how many commits are being made and number of unique committers making them would also be interesting. And other things, I'm sure. Now, if I only had the faintest idea of how to automate something like this ... Stefano, I and others are working on this. http://marc.theaimsgroup.com/?l=xml-apache-generalm=100857962129228w=2 http://www.apache.org/~stefano/forrest/1.5/ - Sam Ruby P.S. Food for thought: wouldn't it be nice if we could somehow merge xml and Jakarta? Then discussions as to where POI should go would be moot. Gump doesn't care about these arbitrary distinctions, why should we? +1 on the principle of merging Jakarta and XML. However, you realize there are technical considerations such as the look and fell of the merged web-site. More importantly, what would be the scope of the merged XML+Jakarta? How should we call the combined project? ApacheGrabBag? SourceForgeII? How about all the C++ projects in XML land? When do you think ApacheGrabBag/SourceForgeII and the httpd projects could be merged? Seriously, I think the idea is worth our consideration. Regards, Ceki -- Ceki Gülcü - http://qos.ch -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- Black holes were created when God divided by zero. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
Gerhard, Is it fair and accurate to say that he came to power within the bounds and rules of a democratic system? At 17:58 04.01.2002 +0100, you wrote: Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- Black holes were created when God divided by zero. -- -- 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: Jakarta Status [was Code conventions]
Sam Ruby wrote: P.S. Food for thought: wouldn't it be nice if we could somehow merge xml and Jakarta? Then discussions as to where POI should go would be moot. Gump doesn't care about these arbitrary distinctions, why should we? The thing with XML is that core products like Xerces are cross-platform. I'm not sure if I'm ready for the equation Jakarta != Java Thinking about it more carefully, I would venture to say that POI (along with Battick, FOP, and Xang) may belong under Jakarta. But I'm not sure that we want to say that Jakarta != Java or XML==Java. I do think it might be helpful to drop the server stipulation from the Jakarta charter. I realized that we are all born of the HTTPD Apache server, but I think the ASF is growing past that. Jakarta should be about the development of open source products on the Java platform. And the ASF should be about promoting meritocratic development, regardless of what it has any ties to the Apache HTTPD. This coincides nicely with the other ASF projects, which are also based around given languages, like PHP. -- 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: Code conventions
In the process Hitler and his gang played a surprisingly high number of dirty tricks. Surprising at least for a non German, since we only get an overview of the WW2 history. Since I work in Germany I have the benefit of the many documentaries about the Nazi era played on TV (history is not forgotten here). I am often quite surprised about how twisted and sophisticated some of those tricks and strategies were. BTW, a lot of those strategies involve scaring and distracting the people with some fictional or real enemy. Have fun, Paulo -Original Message- From: Gerhard Froehlich [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 5:59 PM Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
I am sure Gerhard can give a better answer, but IMHO he abused a lot the system. The truth is that it can happen anywhere if people are not very alert and ready to fight for their rights. It could even happen in the USA and it is quite dangerous to think otherwise (because then you are not alert). Have fun, Paulo -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 6:14 PM Gerhard, Is it fair and accurate to say that he came to power within the bounds and rules of a democratic system? At 17:58 04.01.2002 +0100, you wrote: Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Code conventions
Hi, Gerhard, Is it fair and accurate to say that he came to power within the bounds and rules of a democratic system? Yes and it should remind us, that the democratic system is very imperfect! Even in the USA. A powerful President with deep influence can slowly become more and more powerful until the Parliament is meaningless. And when the country simultaneously is in a deep recession then gnade uns gott. IMO: politics == process howto get more power and control! And a democratic system don't saves us for persons, which want to use this power evil. It just makes the process more bureaucratic. And that's the trick. But you can't compare the democratic system of 1932 with our systems in 2002! But take look on Austria and Jörg Haider. If you are a German native Speaker you should read the current discussion on about bilingual street shields http://derstandard.at/. But don't let this dicussion become political! IMHO politics sucks ;) Gerhard a lightwighted anarchist ;) - I don't suffer from insanity. I enjoy every minute of it. - At 17:58 04.01.2002 +0100, you wrote: Hi, skip/ Any democratic system is imperfect and hence flawed. Hitler was elected democratically although he soon moved to dismantle the system that brought him to power. D'oh, that damn Godwin's Law! Nein ;), Hitler and his NSDAP gets only ~30%. He became Reichskanzler because the other so called democratic parties like Volkspartei and Socialist where so quarreled that they were unable to form a strong coalition to kick this asshole out and preserve my country from this dark 15 years. Therefore the current Reichspräsident Hindenburg called Hitler for the new Reichskanzler, because the existing Parlament was to weak. After his dead '35 Hitler began with the so called Gleichschaltung. Hitler slowly destroyed the democratic system, but he was *never* elected democratic!! skip/ Gerhard -- Black holes were created when God divided by zero. -- -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Status [was Code conventions]
I am 100% for that. Even because: - How server specific is Ant? - And BCEL? - And Log4J? - And ORO? - And Regexp? - And Xerces? - And commons collections, DBCP, Beanutils... And I could push it a bit more. Of course that they are useful to build server stuff... as they could be useful to build client stuff, which is exactly what happens with POI! I think the QUALITY distinction is much more important than the server issue and that should probably be formalized. For me the important arguments being presented are those going on between Stefano and Jon - if there is enough commitment and support for it. (IMO Stefano record looks great. It only makes it better that he knows how and to whom to delegate responsibilities.) Have fun, Paulo Gaspar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, January 04, 2002 6:14 PM Sam Ruby wrote: P.S. Food for thought: wouldn't it be nice if we could somehow merge xml and Jakarta? Then discussions as to where POI should go would be moot. Gump doesn't care about these arbitrary distinctions, why should we? The thing with XML is that core products like Xerces are cross-platform. I'm not sure if I'm ready for the equation Jakarta != Java Thinking about it more carefully, I would venture to say that POI (along with Battick, FOP, and Xang) may belong under Jakarta. But I'm not sure that we want to say that Jakarta != Java or XML==Java. I do think it might be helpful to drop the server stipulation from the Jakarta charter. I realized that we are all born of the HTTPD Apache server, but I think the ASF is growing past that. Jakarta should be about the development of open source products on the Java platform. And the ASF should be about promoting meritocratic development, regardless of what it has any ties to the Apache HTTPD. This coincides nicely with the other ASF projects, which are also based around given languages, like PHP. -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Status [was Code conventions]
Hi, At 11:34 04.01.2002 -0500, you wrote: Ted Husted wrote: What would also help, I think, would be if we published more of our statistics. I know Vincent was working on a download stats page once. I've also seen people post interesting statistics about the posts to the mailing lists. A snapshot of how many commits are being made and number of unique committers making them would also be interesting. And other things, I'm sure. Now, if I only had the faintest idea of how to automate something like this ... Stefano, I and others are working on this. http://marc.theaimsgroup.com/?l=xml-apache-generalm=100857962129228w=2 http://www.apache.org/~stefano/forrest/1.5/ - Sam Ruby P.S. Food for thought: wouldn't it be nice if we could somehow merge xml and Jakarta? Then discussions as to where POI should go would be moot. Gump doesn't care about these arbitrary distinctions, why should we? +1 on the principle of merging Jakarta and XML. However, you realize there are technical considerations such as the look and fell of the merged web-site. More importantly, what would be the scope of the merged XML+Jakarta? How should we call the combined project? ApacheGrabBag? SourceForgeII? How about all the C++ projects in XML land? When do you think ApacheGrabBag/SourceForgeII and the httpd projects could be merged? Seriously, I think the idea is worth our consideration. Regards, Ceki No, I wouldn't merge. Leave the URLs as are, take the Forrest design and change the color ;-)! Gerhard In the beginning there was nothing... then even *that* exploded! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
Ted Husted wrote: I'm not sure if I'm ready for the equation Jakarta != Java http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/native/common/ http://cvs.apache.org/viewcvs/jakarta-ant/src/main/org/apache/tools/ant/taskdefs/optional/dotnet/ Thinking about it more carefully, ... That was the real point of this exercise. ;-) - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
Ceki Gülcü wrote: +1 on the principle of merging Jakarta and XML. However, you realize there are technical considerations such as the look and fell of the merged web-site. More importantly, what would be the scope of the merged XML+Jakarta? The more important question is what is the community model. As the XML bylaws are clones of the Jakarta ones, I would venture to say that they are fairly compatible. How should we call the combined project? ApacheGrabBag? SourceForgeII? Jakarta. [Note: answer above is merely to show that the proposal is not a serious one] One thing I would like people to think about. I see viceral reaction at times to putting things in commons. Or in Avalon/Turbine/Struts, etc. And often there is lengthy debates about whether something belongs in Jakarta or not. Yet, curiously, there seems to be little consideration as to whether something belongs in Apache or not. How many people here know what the Apache board does? Here's a concrete example to illustrate the issue: I've always been under the assumption that at some point a few people in Jakarta land would take a sustained interest in contributing code to Gump, at which point, I would propose it to be a formal subproject. At the present time, it looks like there is a greater possibility of interest of contributing by people in XML land. This lead to a bit of soul searching, and I came to conclusion that if that were to come to pass, I would follow the community. After all, what does it really matter whether the code is jakarta-gump or xml-whatever? - Sam Ruby -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
On Fri, 4 Jan 2002, Ceki Gülcü wrote: - Sam Ruby P.S. Food for thought: wouldn't it be nice if we could somehow merge xml and Jakarta? Then discussions as to where POI should go would be moot. Gump doesn't care about these arbitrary distinctions, why should we? +1 on the principle of merging Jakarta and XML. Agreed that it's definitely worth looking at. However, you realize there are technical considerations such as the look and fell of the merged web-site. Sheesh ... just when I was starting to think that *nothing* could top the rancor of arguing about coding conventions ... :-) Ceki Gülcü - http://qos.ch Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jakarta Status [was Code conventions]
From: Sam Ruby [mailto:[EMAIL PROTECTED]] One thing I would like people to think about. I see viceral reaction at times to putting things in commons. Or in Avalon/Turbine/Struts, etc. And often there is lengthy debates about whether something belongs in Jakarta or not. Yet, curiously, there seems to be little consideration as to whether something belongs in Apache or not. Agreed. How many people here know what the Apache board does? :) Here's a concrete example to illustrate the issue: I've always been under the assumption that at some point a few people in Jakarta land would take a sustained interest in contributing code to Gump, at which point, I would propose it to be a formal subproject. At the present time, it looks like there is a greater possibility of interest of contributing by people in XML land. This lead to a bit of soul searching, and I came to conclusion that if that were to come to pass, I would follow the community. After all, what does it really matter whether the code is jakarta-gump or xml-whatever? You should *always* follow the community. The community gives life to the codebase. Scott -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
Sam Ruby wrote: The more important question is what is the community model. As the XML bylaws are clones of the Jakarta ones, I would venture to say that they are fairly compatible. What about TCL then? I wouldn't actually care if there is one umbrella project or six. But it seemed like the ASF was trying to organize things along platform lines. Should we think about merging with PHP too? Should there actually be umbrella Apache Projects at all? Maybe having proved ourselves, perhaps each product should now stand on its own, as the HTTP Server does. And there would be one PMC for them all. Again, don't care. Just asking. How many people here know what the Apache board does? I used to read the minutes, but they've gotten hard to find. Perhaps they should be posted to the Committer list. Here's a concrete example to illustrate the issue: I've always been under the assumption that at some point a few people in Jakarta land would take a sustained interest in contributing code to Gump, at which point, I would propose it to be a formal subproject. At the present time, it looks like there is a greater possibility of interest of contributing by people in XML land. This lead to a bit of soul searching, and I came to conclusion that if that were to come to pass, I would follow the community. After all, what does it really matter whether the code is jakarta-gump or xml-whatever? Perhaps if it were over here, then there would be more cross-pollination between projects. Likewise with having things like POI in XML land, that Jartian products might use. -- 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: Jakarta Status [was Code conventions]
Hi skip/ Here's a concrete example to illustrate the issue: I've always been under the assumption that at some point a few people in Jakarta land would take a sustained interest in contributing code to Gump, at which point, I would propose it to be a formal subproject. At the present time, it looks like there is a greater possibility of interest of contributing by people in XML land. This lead to a bit of soul searching, and I came to conclusion that if that were to come to pass, I would follow the community. After all, what does it really matter whether the code is jakarta-gump or xml-whatever? Yep it matters because that's mixing of concerns. As an Avalon Committer I only say three words: Separation of Concerns :-)! Beside there is lot of inoffical co-operation. Look at Cocoon and Avalon. Devs in this project are working close together in technical issues though the project aim is completly different. I think you should leave the current diversification. Otherwise I see the danger that the xml-apache group is forced completely towards Java. But that's not the aim of XML! And when we soften Jakarta so that C++ (personally nothing against C) servers could be possible as subprojects or whatever then we even could put everything under www.apache.org and in one mailing list ;)! I know it's hard for us, but try to think as a guy from a entprise sales group ;-). Just thoughts! Gerhard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
i'd just like to point out that i didn't write that bit of code (but
neither did i correct it).
personally speaking, i'm not going to risk having patches vetoed because i
try to correct the original author's coding style.
any committer who has the time and energy to fight is very welcome to
correct the many deviations from the standards that you'll find in the
commons (and in the other projects as well, no doubt).
- robert
On Friday, January 4, 2002, at 01:54 AM, Jon Scott Stevens wrote:
It is amazing to me...with all the discussion about coding styles and
following them, we still have people committing code that doesn't follow
what rules we do have...
on 1/3/02 11:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Re: cvs commit: jakarta-
commons/logging/src/java/org/apache/commons/logging
SimpleLog.java
+if(_showtime) {
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367
Variable names should not start with underscore _ or dollar sign $
characters, even though both are allowed.
http://jakarta.apache.org/site/source.html
All Java Language source code in the repository must be written in
conformance to the Code Conventions for the Java Programming Language as
published by Sun.
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
on 1/4/02 8:05 AM, Bob Jamison [EMAIL PROTECTED] wrote: jakarta.apache.org != Sun That isn't the comparison that we are making here. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
At 10:35 04.01.2002 -0800, you wrote: on 1/4/02 3:28 AM, Ceki Gülcü [EMAIL PROTECTED] wrote: All Java Language source code in the repository must be written in conformance to the Code Conventions for the Java Programming Language as published by Sun. However, some projects may decide to override these defaults and use their own defined conventions. For example, the Turbine project has its own defined conventions which are similar to the Sun standards but specify slightly different conventions. Which really reads: we have conventions but you are free to ignore them -- what people have flocked to do gleefully.. Cheers, Ceki Keyword above: 'defined' Fine distinction. Keyword: fine (pun intended). -- Ceki Gülcü - http://qos.ch -- 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]
Thoughts on Coding Standards
I've been watching the recent 'discussion' on coding conventions with some interest. I promised myself I'd stay out of it, but in the end I just can't. I guess I'm weak that way. When discussion coding conventions we first need to understand *why* they are important. What are coding standards really for? This is an honest question and I'd recommend that before you read much further you stop and try to answer the question for yourself. Over the years I've heard many justifications for coding standards, but only one, in my opinion, is of much real value. Coding standards are not to make 'everything look the same' (the code may look more similar, but that isn't the real goal), they are not to protect coders from making stupid typographical errors (they might, but that isn't their primary purpose). The real purpose for coding standards to IMPROVE SOFTWARE MAINTAINABILITY. Coding standards don't equate to improved maintainability, but they are an important component. Maintainable code has the following attributes: 1) Readable (legible) 2) Understandable 3) Modifiable Readability is related to the textual formatting of the source code. It involves indentation, bracing styles, naming conventions, etc. Outside of entries to the IOCCC (International Obfuscated C Coding Contest), someone one reading code shouldn't have to spend much time trying to figure out if a statement really belongs inside an if block or not. Understandability relates to readability in that readable code is more likely to be understandable, but it involves much more than that. Understandability is the attribute of being able to read a section of code and understand what that code is supposed to accomplish and how it accomplishes it. Understandability relies not only on the code logic being clear but also relies heavily on source code documentation in the form of comments. Understandability can be measured on many levels. For example, what does a given loop accomplish, what does a given method do, what is this class for, how does this class fit into the application as a whole? All of these are questions of understandability. Modifiable code is the opposite of 'brittle' code. Brittle means that a small and seemingly benign change may have huge or catastrophic impact on the system as a whole. Developers are more comfortable making fixes or enhancements to modifiable code because is there is less chance that their changes will have unexpected impacts. Understandable code leads to improved modifiability because obviously developers are less likely to break code that they can readily understand, but it involves much more than this. Modifiability is more about proper design (OO methods, design patterns, etc.) then about the specifics of language syntax or text formatting. Coding conventions can be an important part of developing readable and understandable code. But, when codifying a set of conventions to impose upon developers, it is important to understand how each convention relates to improving maintainable code and then discarding those that really have no direct bearing. Otherwise, the coding conventions are simply one set of developers imposing their will upon the majority by virtue of nothing other than their position of power. I've rambled on longer than I intended so let me finish with two examples to demonstrate. One will be an example of a common coding convention that should be discarded because it does not directly impact maintainability and other is a convention that actually is important. First, bracing formats. As long as a given module follows a consistent strategy for using braces the specifics of that strategy are irrelevant to any rational coding convention. Each developer may have their own pet formatting that they believe is the 'most readable' but in reality, as long as a module uses a consistent format any developer who claims to be a professional in this business should be able to read it with little trouble. Now a simple convention that really is important. Don't define or initialize more than one variable on a single line. Why? Because it reduces readability by making it harder to see at a glance the type or value of a variable. It also impacts modifiability because it is easy to overlook an assignment that's buried in with several others on a single line so a change to code may have unexpected results. OK, that's enough for now, I need to go back to trying to keep my day job. But please, stop debating where the damn braces go, stop trying to impose a strict set of all encompassing rules that apply to all of Jakarta. Focus on defining a small set of basic rules that actually have a real impact on code maintainability and leave it at that. I have a set of coding guidelines that I recently developed for Java developers within my company. At some point, when I have some time, I'll see about removing the Apropos specific stuff and post it here for discussion. Marc Saegesser
Re: proposal for the jakarta startpage
Gerhard Froehlich wrote: Nope. No karma for the Jakarta Site, only for the Avalon project. Your turn ;-). I did post an update this morning, but there apparently a problem with anoncvs that's preventing me from copying the changes over to the main site. -- 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: Code conventions
Peter Donald wrote: So I +1 on suggesting standards for external parts of project, -1 for forcing it uh, I jumped in the middle of a where to place the curly brace code format pissing contest, how cool. For those of you who weren't around, we had the first resolution of this (what later became condensed into the current PMC directives) around 1997 on the jserv-dev mail list. (Jon, remember that?) Sure, it would be cool to have a clear code convention (or a language like Python that more or less doesn't even compile if you don't follow the right conventions) or a benevolent dictator (that used the convention you like!). Unfortunately, we don't have any of those, so the resolution was: most of the java source code out there (well, it was 1997, you know!) used the Sun coding conventions so we started from there, but we decided to be tollerant on *cultural* differences. And *cultural* differences include: editor used, favorite OS, favorite mail client, favorite browser, favorite native language, favorite ice cream flavor... :) Sure, there should be *compromises* and there are some that are very useful and understandable (the use of english as the language, no HTML in email, nice quoting, polite messages, support for old browsers, no ice cream attached to email) and some that are more subject to personal judgement (local variable names, curly brace location, tab vs. space, how many spaces for a tab). When no objective result can be reached, discussions become religious wars. I'd follow Sam suggestions: let's be tollerant. -- 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: Jakarta Status [was Code conventions]
On 1/4/02 12:39 PM, Sam Ruby [EMAIL PROTECTED] wrote: Here's a concrete example to illustrate the issue: I've always been under the assumption that at some point a few people in Jakarta land would take a sustained interest in contributing code to Gump, at which point, I would propose it to be a formal subproject. At the present time, it looks like there is a greater possibility of interest of contributing by people in XML land. This lead to a bit of soul searching, and I came to conclusion that if that were to come to pass, I would follow the community. After all, what does it really matter whether the code is jakarta-gump or xml-whatever? Funny. I've been waiting for it to become a top level project (or at least an Alexandrai project :) -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
On Sat, 5 Jan 2002 03:34, Sam Ruby wrote: Ted Husted wrote: What would also help, I think, would be if we published more of our statistics. I know Vincent was working on a download stats page once. I've also seen people post interesting statistics about the posts to the mailing lists. A snapshot of how many commits are being made and number of unique committers making them would also be interesting. And other things, I'm sure. Now, if I only had the faintest idea of how to automate something like this ... Stefano, I and others are working on this. http://marc.theaimsgroup.com/?l=xml-apache-generalm=100857962129228w=2 http://www.apache.org/~stefano/forrest/1.5/ woohooo P.S. Food for thought: wouldn't it be nice if we could somehow merge xml and Jakarta? +1 -- Cheers, Pete Duct tape is like the force. It has a light side, and a dark side, and it binds the universe together ... -- Carl Zwanzig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
Rule #1 from The Elements of Java Style is:
Adhere to the style of the original
- Original Message -
From: robert burrell donkin [EMAIL PROTECTED]
To: Jakarta General List [EMAIL PROTECTED]
Cc: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, January 04, 2002 12:49 PM
Subject: Re: More abuse of coding styles...
i'd just like to point out that i didn't write that bit of code (but
neither did i correct it).
personally speaking, i'm not going to risk having patches vetoed because i
try to correct the original author's coding style.
any committer who has the time and energy to fight is very welcome to
correct the many deviations from the standards that you'll find in the
commons (and in the other projects as well, no doubt).
- robert
On Friday, January 4, 2002, at 01:54 AM, Jon Scott Stevens wrote:
It is amazing to me...with all the discussion about coding styles and
following them, we still have people committing code that doesn't follow
what rules we do have...
on 1/3/02 11:00 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Re: cvs commit: jakarta-
commons/logging/src/java/org/apache/commons/logging
SimpleLog.java
+if(_showtime) {
http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367
Variable names should not start with underscore _ or dollar sign $
characters, even though both are allowed.
http://jakarta.apache.org/site/source.html
All Java Language source code in the repository must be written in
conformance to the Code Conventions for the Java Programming Language
as
published by Sun.
-jon
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jakarta Status [was Code conventions]
on 1/4/02 4:20 PM, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: They aren't even comparable, are they? Of course not. 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. -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: More abuse of coding styles...
On Sat, 5 Jan 2002 03:19, Steve Downey wrote: http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367 | Variable names should not start with underscore _ or dollar sign $ | characters, even though both are allowed. The _instanceVariable and also the __staticVariable idea makes real good sense to me nowadays. Do you have any arguments against it? (btw; this is a genuine question!).. Because those characters are used by implementors and code generators. all java code generators I use have configurable settings. They are legal, but not intended to be used by programmers. Not relevent for java. In C this may be so but that mainly had to do with how the linker mangled names. And this was more separated out between system-user code -- Cheers, Pete Sorry, I forgot to take my medication today. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: More abuse of coding styles...
On Fri, 4 Jan 2002, Erik Hatcher wrote: Date: Fri, 4 Jan 2002 19:27:52 -0500 From: Erik Hatcher [EMAIL PROTECTED] Reply-To: Jakarta General List [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Subject: Re: More abuse of coding styles... Rule #1 from The Elements of Java Style is: Adhere to the style of the original IIRC, we actually had this rule explicitly in the JServ code conventions ... looks like it didn't make the transition into the Jakarta docs though. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/beanutils build.xml
on 1/4/02 4:31 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Conform to the recently agreed (on [EMAIL PROTECTED]) convention of including the Apache License inside the JAR file, at META-INF/LICENSE.txt How about documenting that convention on the website? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
