Re: [Request For Comment] POI @ apache

[Andrew C. Oliver]

Hi Pete,


>> Me to. POI doesn't seem to have anything to do with XML and FOP is 
>> essentially a renderer for a XML dialect right ?
 
> POI are codecs for reading different office formats in java. Sounds
much more 

correction:  reading and writing (I don't bother with simple "readers",
there are a hundred of those out there).  (not to be pedantic just to
distinguish the purpose)

>suited to jakarta than xml ... but even then it does seem to be out of
scope 
>- what the hell has it got to do with serverside technologies ? But
then 
>again I have no problem with this ;) 

Well POI is pretty much strictly used on serverside projects.  I've yet
to hear from a user who is currently using this in a clientside
application.  

A typical scenario for POI's HSSF (the Excel API), for instance, would
be for instance that you have a web application that provides a
financial report in HTML.  Well the accounting department insists on
having it in Excel format.  You have a few good and bad solutions, but
POI's HSSF API (codec if you prefer) will allow you to serve the XLS
file from your Unix server running Tomcat for instance.  You could of
course have the opposite scenario (the accounting department uploading
the XLS) and HSSF can help with that too.  Either way POI has NO GUI. 
It could be used of course in a client app if you wanted, but Tomcat is
being used by Netbeans for something or the other so go figure on what
is strictly serverside so to speak.  

Hope that clears things up  (and I hope it doesn't make you doubt that
Tomcat is a serverside component ;-p).

-Andy


>-- 
>Cheers,

>Pete



-- 
www.superlinksoftware.com
www.sourceforge.net/projects/poi - port of Excel format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!


The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Ted Husted]

Any time we want switch from Sun's conventions to the Elements of Java
Style, my +1 is cocked and ready. 

"Craig R. McClanahan" wrote:
> 
> 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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Craig R. McClanahan]

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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Peter Donald]

On Sat, 5 Jan 2002 03:19, Steve Downey wrote:
> > 
> >
> > | "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:   
For additional commands, e-mail: 

Re: [Request For Comment] POI @ apache

[Peter Donald]

On Sat, 5 Jan 2002 02:53, Paulo Gaspar wrote:
> > -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?

Me to. POI doesn't seem to have anything to do with XML and FOP is 
essentially a renderer for a XML dialect right ?

POI are codecs for reading different office formats in java. Sounds much more 
suited to jakarta than xml ... but even then it does seem to be out of scope 
- what the hell has it got to do with serverside technologies ? But then 
again I have no problem with this ;) 


-- 
Cheers,

Pete

---
Be nice to your friends. If it weren't 
for them, you'd be a complete stranger.
---

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-commons/beanutils build.xml

[Jon Scott Stevens]

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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Geir Magnusson Jr.]

On 1/4/02 7:38 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:

> 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
> 

Certainly!  But that's a whole other kettle of fish :)

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Now what do we do?"


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Request For Comment] POI @ apache

[Jon Scott Stevens]

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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Jon Scott Stevens]

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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Erik Hatcher]

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) {
> >
> > 
> >
> > "Variable names should not start with underscore _ or dollar sign $
> > characters, even though both are allowed."
> >
> > 
> >
> > "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:

> > For additional commands, e-mail:

> >
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Geir Magnusson Jr.]

On 1/4/02 6:58 PM, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:

> "Craig R. McClanahan" wrote:
>> 
>> 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 ... :-)
> 
> Yeah, Anakia vs. Cocoon2 would be a fun pissing contest to watch :) NOT!

They aren't even comparable, are they?

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Request For Comment] POI @ apache

[Peter Donald]

On Sat, 5 Jan 2002 08:18, Jon Scott Stevens wrote:
> >  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?

+1 from me

-- 
Cheers,

Pete

--
 The fact that nobody understands you doesn't 
 mean you're an artist.
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Peter Donald]

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-general&m=100857962129228&w=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:   
For additional commands, e-mail: 

Re: [Request For Comment] POI @ apache

[Stefano Mazzocchi]

Jon Scott Stevens wrote:
> 
> 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.

Funny, I share Sam's vision entirely.

> >  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. 

Here is my *FIRST* email on the subject (Thu, 03 Jan 2002 01:47:02
+0100)

> Please, keep me copied since I'm not currently subscribed to 
> general@jakarta
>
> "Andrew C. Oliver" wrote:
>
> >I don't see any convincing reason to bring POI to Jakarta, unless I see
> >that
> >you have a Jakarta PMC member champion your cause. Stefano's
> >recommendation
> >to you isn't enough, he or someone else needs to be a committer and
> >interested in working and overseeing your project.
>
>I do.

On all the others mail lists I'm subscribed, that would have been
enough, but not here.

That makes me wonder about the real causes of this "whole fucking mess"
and "jakarta is fucked up today" feelings of yours...

-- 
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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Stefano Mazzocchi]

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-general&m=100857962129228&w=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?

I fully resonate with this: I have *always* hated projects as
containers. I think Tomcat is a project, not Jakarta. I think Xerces is
a project not XML (which conflicts with XML the language).

In the future, I would simply love to see

 www.apache.org/tomcat

go along with 

 www.apache.org/httpd

and a good software map to tell the story, indicate the overlap, outline
those distinctions and so on.

It would also remove the need for PMCs and give the ASF board a reason
to exist.

The reason question is: could we stand the heat of a [EMAIL PROTECTED]
mail list?

-- 
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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Stefano Mazzocchi]

"Craig R. McClanahan" wrote:
> 
> 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 ... :-)

Yeah, Anakia vs. Cocoon2 would be a fun pissing contest to watch :) NOT!

-- 
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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Geir Magnusson Jr.]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Stefano Mazzocchi]

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:   
For additional commands, e-mail: 

Re: Jakarta Status [or proposal for the jakarta startpage]

[Sam Ruby]

Ceki Gülcü wrote:
>
> What? Contribute to Gump to make it more powerful and nagging? I rather
> iron my old shirts before scratching that itch.  Is it possible that Gump
> is complete such that no one has anything valuable left to contribute?

Sheesh.  Some people have no vision.   ;-)

Did you know that it already has much of the data required to produce the
jakarta start page that people describe?  All that is required is a
stylesheet...  Or if we need more data, there's another hole waiting for
someone to fill.  I'll make it easy, the raw data and a preprocessed,
merged, and sorted version can be found at the following URLs:

   http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project/
   http://jakarta.apache.org/builds/gump/latest/merge.xml

Other useful byproducts that could stand to be enhanced, both from a visual
perspective and a content perspective:

   http://jakarta.apache.org/builds/gump/latest/xref.html
   http://nagoya.apache.org/~rubys/gump/javadoc.html

I'm also looking to improve the process by which the popular daily binaries
are produced.  More ideas can be found at the following URLs:

   http://marc.theaimsgroup.com/?l=xml-apache-general&m=100857962129228&w=2
   http://www.apache.org/~stefano/forrest/

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Code conventions

[Gunnar Rønning]

* Ceki Gülcü <[EMAIL PROTECTED]> wrote:
|
| >enough that another referendum could be held for the issue.
| 
| Laugh all you want. Referenda are great. Ask any Swiss citizen. 

Well, people are to stupid to know the issues ;-) 

Ask any Norwegian with a pro European Union membership stand ;-)

-- 
Gunnar Rønning - [EMAIL PROTECTED]
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Ceki Gülcü]

At 12:39 04.01.2002 -0500, you wrote:
>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?

Yah, they have cocktails, go to the beach and barbecue.

>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.  

What? Contribute to Gump to make it more powerful and nagging? I rather 
iron my old shirts before scratching that itch.  Is it possible that Gump
is complete such that no one has anything valuable left to contribute?

>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?

Go for it. 


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: proposal for the jakarta startpage

[Jon Scott Stevens]

on 1/4/02 12:41 PM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> 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. 

I did a cvs update for you.

-jon

-- 
Standard rules apply: Ask any questions, and you get the job. ;-)


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [Request For Comment] POI @ apache

[Jon Scott Stevens]

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:   
For additional commands, e-mail: 

RE: proposal for the jakarta startpage

[Gerhard Froehlich]

Ted,
Hmm, I see it now.
Anyway >kool< work dude and thx. 

Next time I will do it ;-)

  Gerhard
 
"Horngren's Observation (generalized): The real world is a special case."

>-Original Message-
>From: Ted Husted [mailto:[EMAIL PROTECTED]]
>Sent: Friday, January 04, 2002 9:41 PM
>To: Jakarta General List
>Subject: 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:   
>For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: proposal for the jakarta startpage

[Ted Husted]

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:   
For additional commands, e-mail: 

Thoughts on Coding Standards

[Marc Saegesser]

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: [Request For Comment] POI @ apache

[Ted Husted]

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:   
For additional commands, e-mail: 

Re: [Request For Comment] POI @ apache

[Sam Ruby]

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:   
For additional commands, e-mail: 

Re: [Request For Comment] POI @ apache

[Jon Scott Stevens]

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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Ceki Gülcü]

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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Jon Scott Stevens]

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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Jon Scott Stevens]

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'

-jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta Status [was Code conventions]

[Gerhard Froehlich]

Hi



>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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Ted Husted]

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:   
For additional commands, e-mail: 

RE: Re: More abuse of coding styles...

[Edson Alves Pereira]

  Why not you create a page that show the code style that you want?

  I think that:

  if ( showtime )
  {
...
  }

  Is a valid statement and besides there are a lot of projects from Jakarta, 
SourceForge and Companies around the world that use this. Turbine has a page that show 
it´s code style.

robert burrell donkin <[EMAIL PROTECTED]> wrote:

>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) {
>>
>> 
>>
>> "Variable names should not start with underscore _ or dollar sign $
>> characters, even though both are allowed."
>>
>> 
>>
>> "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:   
>> For additional commands, e-mail: 
>>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
-- 
///
Better well done than well said.
 --//--
To follow the path:
look to the master,
follow the master,
walk with the master,
see through the master,
become the master.

Modern Zen poem
///



__
Your favorite stores, helpful shopping tools and great gift ideas. Experience the 
convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta Status [was Code conventions]

[Scott Sanders]

> 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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Craig R. McClanahan]

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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Sam Ruby]

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:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Sam Ruby]

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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[robert burrell donkin]

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) {
>
> 
>
> "Variable names should not start with underscore _ or dollar sign $
> characters, even though both are allowed."
>
> 
>
> "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:   
> For additional commands, e-mail: 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Jakarta Status [was Code conventions]

[Gerhard Froehlich]

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-general&m=100857962129228&w=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:   
For additional commands, e-mail: 

RE: Jakarta Status [was Code conventions]

[Paulo Gaspar]

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:   
> For additional commands, e-mail: 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Code conventions

[Gerhard Froehlich]

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 .

But don't let this dicussion become political!
IMHO politics sucks ;)

  Gerhard


-
I don't suffer from insanity. I enjoy every minute of it.
-

>At 17:58 04.01.2002 +0100, you wrote:
>>Hi,
>>
>>
>>
>>>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!!
>>
>>
>>
>>  Gerhard
>>
>>
>>
>>
>>--
>>Black holes were created when God divided by zero.
>>--
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:   
>>For additional commands, e-mail: 
>
>--
>Ceki Gülcü - http://qos.ch
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Code conventions

[Paulo Gaspar]

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,
> >
> >
> >
> >>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!!
> >
> >
> >
> >  Gerhard


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Request For Comment] POI @ apache

[Scott Sanders]

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

> -Original Message-
> From: Paulo Gaspar [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, January 04, 2002 7:54 AM
> To: Jakarta General List
> Subject: 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:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Code conventions

[Paulo Gaspar]

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,
>
> 
>
> >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!!
>
> 
>
>   Gerhard


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Ted Husted]

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:   
For additional commands, e-mail: 

RE: Code conventions

[Ceki Gülcü]

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,
>
>
>
>>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!!
>
>
>
>  Gerhard
>
>
>
>
>--
>Black holes were created when God divided by zero.
>--
>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Code conventions

[Gerhard Froehlich]

Hi,



>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!!



  Gerhard




--
Black holes were created when God divided by zero.
--




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Ceki Gülcü]

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-general&m=100857962129228&w=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:   
For additional commands, e-mail: 

RE: More abuse of coding styles...

[Gerhard Froehlich]

Hi,



>> if (something) {
>> 
>> }
>> 
>> 
>> ;)
>> 
>
>Tsk tsk. The RIGHT WAY is really
>if (something)
>   {
>   statements();
>   }

Waah, no way dude!!!
http://python.sourceforge.net/peps/pep-0007.html
The C style is the only way. Don't forget, that
C is the mother of all programming languages!
;)

  Gerhard
 
--
Black holes were created when God divided by zero.
--


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Code conventions

[Ceki Gülcü]

At 16:01 04.01.2002 +, you wrote:
>Ceci wrote:
>
>> The inability of the PMC to take initiative stems from the Apache
>> voting process
>
>
>
>> The current system   is inappropriate for managing large projects
>like
>> Jakarta.
>
>
>
>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.

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!

The PMC consists of a body of over 10 individuals who each have veto power and 
different interests.

>IMHO (as this whole spiel is) referenda would therefore render the PMC
>irrelevant.

Not necessarily. It depends how the roles and competencies of the
PMC and that of the body of committers are defined.

>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.

Not only is reaching consensus in larger groups harder, it is 
plain impossible. Thus, we should at least study other ways for taking 
decisions, for example by majority vote.

Hmm, I wonder who will -1 that first.

>> 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?

Yes, the current system could be adapted. 

Many people are probably wondering whether this discussion is not too political.
We are here to code not to chatter, right? 


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Sam Ruby]

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-general&m=100857962129228&w=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:   
For additional commands, e-mail: 

RE: More abuse of coding styles...

[Steve Downey]

> |
> | 
> 
> |
> | "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. They
are legal, but not intended to be used by programmers. 

> 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) {
> 
> }
> 
> 
> ;)
> 

Tsk tsk. The RIGHT WAY is really
if (something)
{
statements();
}


<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named.  Any use, copying or disclosure by any other person is strictly
prohibited.  If you have received this transmission in error, please notify
the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Jakarta Status [was Code conventions]

[Ted Husted]

Danny Angus wrote:
> 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.

I agree. Personally, I don't see that anything is broken. Things don't
happen as quickly as any of us would like, but they are happening.
Struts now supports Velocity along with JavaServer Pages. Turbine is
exposing more of its components, and Torque may graduate to a subproject
in its own right. Avalon is up to speed, and just made a significant
release. We've added BCEL, Lucene, and others to our midst this year.
Doug Cutting was going to step back from Lucene, but it looks like we've
drawn him back into the game ;-). The Commons has made several releases,
and is actively whiteboarding severl exciting new products, like the
Workflow and DynaBeans. 

I think the newsletter will help bring more of this out. There mis ore
good news than people imagine. We just don't blow our own horn much.

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 ...


-- 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:   
For additional commands, e-mail: 

Re: Code conventions

[Ceki Gülcü]

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 

Re: Code conventions

[Ted Husted]

Sam Ruby wrote:
> 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.  ;-)

+1 -- Any Jikes developers out there? It would be cool if the compiler
issued the Jon-style warnings!


-- 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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Bob Jamison]

Jon Scott Stevens 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."
>
>-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 K&R 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:   
For additional commands, e-mail: 

RE: Code conventions

[Danny Angus]

Ceci wrote:

> The inability of the PMC to take initiative stems from the Apache
> voting process



> The current system   is inappropriate for managing large projects
like
> Jakarta.



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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Berin Loritsch]

Endre Stølsvik wrote:

> On Thu, 3 Jan 2002, Jon Scott Stevens wrote:
> 
> 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!)..


Honestly, I don't like the underscore notation.  If there is any deviation
from that, it would be simple scope modifiers like m_memberVariable.

I have adopted the practice of explicitly scoping all my veriables.  It is
better supported by IDEs with autocompletion, so for me it even reduces
typing.  Also, I try not to ever use a parameter that is the same as a
member variable.


> 
> And while talking about code conventions; people writing like this:
> 
> if (something)
> {
> 
> }


As long as the deviation is *documented*.  If you supercede the Sun
conventions, you must document exactly how it is done.  Examples of
this are in both the Struts and the Avalon projects.  Both clearly
identify coding practices that supercede Sun's conventions.

This also means that *all* Commons code must adopt the coding convention.

Honestly, the aditional space forced by the brace on the following line
_does_ increase legibility.


> 
> 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) {
> 
> }
> 
> 
> ;)
> 
> 



-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [Request For Comment] POI @ apache

[Paulo Gaspar]

> -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:   
For additional commands, e-mail: 

Re: Code conventions

[Sam Ruby]

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.  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.

> 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.

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.

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.

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).

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.

- Sam Ruby


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Code conventions

[Danny Angus]

> 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:   
For additional commands, e-mail: 

Re: Code conventions

[Ceki Gülcü]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Ceki Gülcü]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Ceki Gülcü]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Ted Husted]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Peter Donald]

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 ;)

> 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. 

> 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


-- 
Cheers,

Pete

--
I just hate 'yes' men, don't you Smithers?
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Code conventions

[Peter Donald]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Peter Donald]

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:   
For additional commands, e-mail: 

Re: [Request For Comment] POI @ apache

[Stefano Mazzocchi]

[note: no need to keep me copied since I subscribed]

Jon Scott Stevens wrote:
> 
> on 1/3/02 5:31 AM, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> 
> > Exactly, ignoring M$ doesn't make it go away. I would say the opposite:
> > there are tons of companies that base their document systems on M$
> > software and would like to move to a more open world but they simply
> > can't afford loosing the legacy data, so their managers decide to stick
> > with M$ stuff.
> >
> > I would say that an exporting tool would rather do the opposite than
> > encourage people to use M$ software, would encourage much more those who
> > already use it to get away from it.
> 
> Based on the ranking that it is at now, keeping the project at sourceforget
> clearly doesn't hurt it at all. I don't see that as a reason to move it to
> the ASF.
> 
> > I'm not part of the Jakarta PMC (even if I've been) but I am an ASF
> > member, which is even a higher status community-wise.
> 
> > Please, explain why you think my community sponsoring wouldn't be enough
> > as a warranty for your vote.
> 
> You need to be willing to step up and help integrate their project into the
> ASF. In other words, you (or another PMC member) needs to be willing to
> watch over the project. 

I am willing to do that.

> Based on your past history of appearing and
> disappearing (and the fact that you aren't a PMC member anymore), I'm not
> confident that you will stick around long enough to make sure that they
> integrate well and play well. 

I understand and appreciate your concern, but I would like to remind you
that I never left any project without making sure that a community could
stand my absence.

I are fully aware of the fact that I personally bootstrapped JMeter,
Avalon, JAMES (on jakarta.apache.org) and Cocoon, FOP, Batik and XIndice
(on xml.apache.org).

Those times where I could not provide my continuous and active presence,
I made the people know and *never* left the community without a clear
leadership or guidance.

For JMeter, a votation was made to elect the new coordinator and I
remained there for months before leaving. The project has released two
major versions since then.

For JAMES, I passed the hand over to Federico and Serge. Several
software releases and major improvements happened.

For Avalon, Federico first then Berin and Peter. No need to question the
health of this community. Federico earned the ASF membership for those
efforts.

For Cocoon, Giacomo, then Carsten. Giacomo earned the ASF membership for
that. Again, no need to question the health of the community.

For FOP, Arved. Arved earned the ASF membership for that. Same thing for
the community status.

For Batik, there isn't one project coordinator, but the community is
very successful as it's reaching full compatibility with W3C
recommendations.

For XIndice, I'm still the sponsoring member and no plans to leave until
the software goes in the direction I would like it to see it going.

> What happens to their project when you decide
> you don't feel like keeping an eye on them anymore?

100% of the communities I bootstrapped under ASF are still alive and
healthy. Several individuals on these communities earned ASF membership.
They count several thousands of users and developers.

What I'm stating here, in case it's not clear, is my intention to help
the POI codebase to generate a community around the needs to
import/export data from M$ binary formats that I consider very important
legacy data in many situations.

I won't leave the community until it is solid enough to withstand my
absence, should it take 2 months or 2 years.

I hope my present commitment and my past results clear up any doubts on
my sponsoring of this code donation.

-- 
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:   
For additional commands, e-mail: 

Re: Code conventions

[Geir Magnusson Jr.]

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:   
> For additional commands, e-mail: 
> 

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
"Now what do we do?"


--
To unsubscribe, e-mail:   

Re: Code conventions

[Ted Husted]

Ceki Gülcü wrote:
> We keep saying that Jakarta is not SourceForge. How can this be if
> each project can act totally independently?

I think the ASF page says it best:

"The Apache projects are characterized by a collaborative, consensus
based development process, an open and pragmatic software license, and a
desire to create high quality software that leads the way in its field.
We consider ourselves not simply a group of projects sharing a server,
but rather a community of developers and users."

In the US, we have a national community, state communities, and then
county, city, town and village communites. 

For most matters, each sub-community can create many rules of their own.
In one state you can turn right on red, in another you can't. This
doesn't mean that both states are not part of the same national
community. 

The Jakarta subprojects are the same way. Right now, we have give the
subprojects permission to declare their own conventions, or use the
project defaults. I think that's fine, we just have to remind the
subprojects to use their own conventions. 

But if a subproject said, "We're going to scuttle the Apache Software
License, let one Committer make all the decisions, and disband everyone
else's veto power", they would quickly find their access to the CVS cut
off. 

It's a matter of scope and tolerances. I think selecting a coding
convention is within the scope of the subprojects, so long as they
select one and stick to it. 

-- 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:   
For additional commands, e-mail: 

Re: Code conventions

[Ceki Gülcü]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Geir Magnusson Jr.]

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:   
> For additional commands, e-mail: 
> 

-- 
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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Arnaud Vandyck]

Jon Scott Stevens <[EMAIL PROTECTED]> 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) {
> 
> 
> 
> "Variable names should not start with underscore _ or dollar sign $
> characters, even though both are allowed."

Sun Certified Programmer for Java2 Platform:

Question:

5. Which is a valid identifier? 

o false
o default
o _object
o a-class

funny! :))  allowed, not recommended, but  a part of  the questions at
the exam :)

-- Arnaud, STE-Formations Informatiques, fapse, ULg, .BE

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Code conventions

[Ceki Gülcü]

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.

The threat is to Jakarta's *nature* and it comes from our indecisiveness. 

Real problems I see is 

1) lack of focus,
2) duplication between projects,
3) lack of common procedures for doing things.

Are these perceived as problems by others or is it just my
imagination?


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Code conventions

[Geir Magnusson Jr.]

On 1/4/02 7:07 AM, "Ted Husted" <[EMAIL PROTECTED]> wrote:

> "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.


Agreed - and that seems to me to be another way of saying that each Jakarta
subproject is a community into itself, with conventions and practices
determined by that community (modulo the basic procedural and licensing
practices of the ASF).

When you remind me about conventions in my codebase, you are in essence
becoming a part of my community. (Which is cool...)


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: proposal for the jakarta startpage

[Arnaud Vandyck]

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:   
For additional commands, e-mail: 

RE: More abuse of coding styles...

[Stephane Bailliez]

> -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:   
For additional commands, e-mail: 

Re: Code conventions

[Ted Husted]

"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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Ted Husted]

I agree with Jon in that when people agree to become a Committer to a
subproject they agree to follow the rules of that subproject, the
Jakarta project, and the Apache Software Foundation.

As it stands, each subproject is entitled to document their own coding
conventions. When none are specified, then the default Jakarta
guidelines apply. 

I believe that PMC members are obligated to remind people of the rules.
It is up to the Committers to a subproject to see that the code is
changed, but it is our job to point out the transgression. (In the same
way that GUMP points out other technical problems.) Of course, other
members of the community are also invited to help us watch our
collective backs. 

Personally, I believe that everyone here is a consummate professional,
or wants to be, and following the coding conventions of your codebase is
a hallmark of professionalism. When I screw up, I certainly want someone
to point it out to me, as Jon has started to do. A word to wise should
be sufficient.

As Sam mentioned, it is unlikely that the PMC or ASF is going to shut
down a codebase for not following their conventions. But we should
exercise our obligation to nag people until the commits come into
compliance or the conventions for the subproject are amended. 

AFAIK, a change to a subproject coding conventions would be a Product
Change.

-- 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/


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) {
> 
> 
> 
> "Variable names should not start with underscore _ or dollar sign $
> characters, even though both are allowed."
> 
> 
> 
> "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:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Code conventions

[Geir Magnusson Jr.]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Geir Magnusson Jr.]

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?


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Ted Husted]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Ceki Gülcü]

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?


--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Ceki Gülcü]

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) {
>
>
>
>"Variable names should not start with underscore _ or dollar sign $
>characters, even though both are allowed."
>
>
>
>"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:   
>For additional commands, e-mail: 

--
Ceki Gülcü - http://qos.ch



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: More abuse of coding styles...

[Ceki Gülcü]

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:   
For additional commands, e-mail: 

Re: Code conventions

[Ceki Gülcü]

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:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Geir Magnusson Jr.]

On 1/4/02 5:26 AM, "Kief Morris" <[EMAIL PROTECTED]> wrote:

> 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
> 

Of course, you can spend hours looking for the following typo :

 public void setSomething( Object somthing )
 {
   this.something = something;
 }


"Look kids, Big Ben.  Can't change 'something'"


-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Geir Magnusson Jr.]

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) {
> |
> | 
> |
> | "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:   
For additional commands, e-mail: 

RE: More abuse of coding styles...

[Stephane Bailliez]

> -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:   
For additional commands, e-mail: 

RE: More abuse of coding styles...

[Kief Morris]

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:   
For additional commands, e-mail: 

RE: More abuse of coding styles...

[Stephane Bailliez]

> -Original Message-
> From: Jeff Turner [mailto:[EMAIL PROTECTED]]

[...]
> 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.

is in the same group as the no-brace:

 if (condition)   <...180 col...>  uWillNeverFindMe();
doSomething(); 

or
 if (condition)
doSomething();
doSomethingToConfuseMe();

But whatever the pain is: I'm following the code conventions established
here.

"When in Rome do as the Romans do."

I'm the lucky user of Intellij IDEA which has a code layout feature that
allows to reformat the whole code in a snap w/ specific code style,
reorganize imports and remove useless one. I'm using this extensively and
this is damn cool.

Stephane

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: More abuse of coding styles...

[Endre Stølsvik]

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) {
|
| 
|
| "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!)..

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) {

}


;)

-- 
Mvh,
Endre


--
To unsubscribe, e-mail:   
For additional commands, e-mail: