Re: TRACE level [WAS] Jakarta: Confederation or Single Project?

[Ceki Gülcü]

At 08:42 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote:

On Dec 20, 2003, at 8:40 AM, Ceki Gülcü wrote:
Subsequent to the demand for the TRACE level expressed by a number of 
user, there is every reason to believe that a vote will be held on this 
topic before log4j 1.3 is released. However, there is still time as log4j 
1.3 will not be released in the immediate future.
Good.  that gives me time to continue badgering in public. See :

http://www.theserverside.com/home/thread.jsp?thread_id=22944

I hope you are taking this with the good nature in which it is intended.
No worries. Although my reply was somewhat dry, the good intentions of your 
comments were totally clear. I definitely have to get myself a sense of 
humor. Unfortunately, you can't buy nor open source humor.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: TRACE level [WAS] Jakarta: Confederation or Single Project?

[Ceki Gülcü]

At 08:31 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote:


Can we have TRACE as a supported level?

Subsequent to the demand for the TRACE level expressed by a number of user, 
there is every reason to believe that a vote will be held on this topic 
before log4j 1.3 is released. However, there is still time as log4j 1.3 
will not be released in the immediate future.

--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Jakarta: Confederation or Single Project?

[Ceki Gülcü]

Log4j is not leaving. It is simply moving to a new room in the house,
a room with a different label but still located within the same house.
As any house, this house offers protection and comfort to its
inhabitants. It is a place where developers can unleash their creative
powers onto the world. But this house is unique in its degree of openness
and tolerance. Apache is a great place to be regardless of the room
you chose.
As for log4j, its developers will continue to be involved with
Jakarta. Many of us use Jakarta products in our daily work. Moreover,
without the software contained in Jakarta, there wouldn't be much use
for log4j.
So there are no goodbyes to be said, we are just next door. No need to
put on shoes, you can hang on to your slippers. Our door is open, you
don't have to knock when you come in.
At 07:23 AM 12/20/2003 -0500, Geir Magnusson Jr. wrote:

On Dec 19, 2003, at 3:33 PM, Costin Manolache wrote:

Ted Husted :


[SNIP]

I agreed w/ every word from Costin.

And look what's happening with logging: Now that it's a TLP, they are 
bringing-in the various Log4J compatibles. Now, there can be one Apache 
logging project serving every platform. That's community-building!

Is logkit included in the logging TLP ? What about commons-logging ?

I agree with you that the logging TLP does define a community ( just 
like  jakarta or httpd ). It's a separate PMC bringing togheter different 
codebases and people.

It remains to be seen if log4j as a TLP will be better than log4j as part 
of jakarta. There are plenty of TLPs - like apache-commons - that
don't seem to be much better than sub-projects like jakarta-commons.
Agreed.  JC is a vibrant sub-project with ties to may Jakarta 
sub-projects.  I think that important and valuable.  I think log4j will do 
fine, and they can always come back.  It's not clear what kind of synergy 
the log4* projects will bring together, but will be interesting to watch.

I had such mixed emotions about log4j leaving, as I think it's going to 
take a bit of our community away.  On the other hand, I support the 
freedom of the log4j community to choose it's own path, and that wins out 
with me.

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCEMENT] Apache Logging Services project

[Ceki Gülcü]

Good morning to all,

The log4j developers are pleased to announce that the Board of
Directors of the Apache Software Foundation unanimously passed a
resolution for the creation of the Apache Logging Services project. A
copy of the resolution can be found at:
http://nagoya.apache.org/wiki/apachewiki.cgi?LoggingApacheOrg/BoardResoluion

The Logging Services project is intended to provide cross-language
logging services for purposes of application debugging and
auditing. The discussions leading to the submission of this resolution
can be found at:
 http://marc.theaimsgroup.com/?t=10711552621&r=1&w=2

We should also mention that thanks to the relentless efforts of many
developers and in particular those of Scott Deboy, we currently have
inter-operability between the following projects:
 * Log4Cxx (c++)
 * Log4CPlus
 * Log4j
 * Log4Net
 * Log4Perl
 * Log4PHP
 * JDK1.4's util.logging framework
There is still much work ahead bringing in the various projects to
work together within the Logging Services Project. The process is
likely to take a little while. In the mean time, we will continue to
do what we like best, that is developing open source software.
Happy holidays to all,

--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Only 17 days left to register at ApacheCon!

[Ceki Gülcü]

Greetings to all,

I just wanted to bring your attention to the fact that there
are only 17 days left for registering at ApacheCon US/2003!
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JSP editor for Eclipse

[Ceki Gülcü]

Thanks Scot.

I'm mainly interested in syntax highlighting and also tag completion, e.g. 
adding  after a . The lomboz editor does not seem to do tag completion.

At 07:54 AM 10/27/2003 -0800, Scot Hale wrote:
I am using the Lomboz plugin, which is much more than a jsp editor, but it
syntax colors nicely.
-Original Message-
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]
Sent: Monday, October 27, 2003 2:46 AM
To: [EMAIL PROTECTED]
Subject: JSP editor for Eclipse
Hello all,

I am looking for a JSP editor for Eclipse. Any recommendations on this
front?
--
Ceki Gülcü
  For log4j documentation consider "The complete log4j manual"
  ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
  import org.apache.Facetime;
  ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JSP editor for Eclipse

[Ceki Gülcü]

Hello all,

I am looking for a JSP editor for Eclipse. Any recommendations on this front?

--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Fwd: Reminder: Hyper-Early Bird Registration Ends Soon

[Ceki Gülcü]

FYI

Date: Fri, 26 Sep 2003 09:35:38 -0700 (PDT)
From: Sally Khudairi <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Reminder: Hyper-Early Bird Registration Ends Soon
 + + ONLY 4 DAYS LEFT + +

Hyper-Early Bird Registration for ApacheCon 2003 is
available until 23.59ET on 30 September.
By registering now, you can save up to US$400!

   ApacheCon US 2003
   16-19 November 2003
   Alexis Park Resort
   Las Vegas, Nevada, US
More than 60 sessions highlight core and
next-generation Apache server tools, offering a wide
range of beginner, intermediate and advanced sessions.
Learn firsthand the latest developments in Apache, the
world's most popular Web server software, as well as
key open source projects, including PHP, Perl, XML,
Java, MySQL, and WebDAV. ApacheCon 2003 is going to be
a great event with a three-day vendor expo, social
activities, BOFs and more.  We want you to be a part
of it!
   Hyper-Early bird registration fee: US$499
   After 30 September: US$599
   After 20 October: US$799
   After 16 November: US$899
Register today at http://www.apachecon.com/
We look forward to seeing you there!
- Sally Khudairi
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Registration to ApacheCon US 2003 is open

[Ceki Gülcü]

The page

 http://www.apachecon.com/2003/US/html/travel.html

should be be updated soon.

At 01:42 PM 9/15/2003 -0500, you wrote:
At which hotel is ApacheCon?

-dain

On Monday, September 15, 2003, at 01:29 PM, Ceki Gülcü wrote:

Registration Opens for ApacheCon 2003, the Global Hub for All Things
Apache ­
ApacheCon 2003, the official conference of the Apache Software
Foundation (ASF), will be held November 16-20, 2003 in Las Vegas,
Nevada. More than 60 sessions highlight core and next-generation
Apache server tools, offering a wide range of beginner, intermediate
and advanced sessions. Learn firsthand the latest developments in
Apache, the world's most popular Web server software, as well as key
open source projects, including PHP, Perl, XML, Java, MySQL, and
WebDAV. Register today at http://www.apachecon.com/
You can find the press release at:

  http://www.marketwire.com/mw/release_html_b1?release_id=57498

--
Ceki Gülcü


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Registration to ApacheCon US 2003 is open

[Ceki Gülcü]

Registration Opens for ApacheCon 2003, the Global Hub for All Things
Apache ­
ApacheCon 2003, the official conference of the Apache Software
Foundation (ASF), will be held November 16-20, 2003 in Las Vegas,
Nevada. More than 60 sessions highlight core and next-generation
Apache server tools, offering a wide range of beginner, intermediate
and advanced sessions. Learn firsthand the latest developments in
Apache, the world's most popular Web server software, as well as key
open source projects, including PHP, Perl, XML, Java, MySQL, and
WebDAV. Register today at http://www.apachecon.com/
You can find the press release at:

  http://www.marketwire.com/mw/release_html_b1?release_id=57498

--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 import org.apache.Facetime;
 ApacheCon US 2003, 18-21 November http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Publicizing ApacheCon 2003

[Ceki Gülcü]

My bad!

At 03:03 PM 9/4/2003 -0400, you wrote:
Actually, as registration isn't open yet, the early-bird is quite a farce.

-Brian

On Thursday, September 4, 2003, at 02:31 PM, Andrew C. Oliver wrote:

Christ, they just got it together.  While I'm covered, folks were for months
asking "Are we having an apachecon" and then it was barely advertised with
no sessions scheduled yet and early bird is already over?  If I were any joe
off the street I'd probably want to at least have some vague idea what would
be covered before registering even if I wanted to register as early as
possible.....
On 9/4/03 12:13 PM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

If I am not mistakem, early-bird registration seems to be already over...

Anyway, I added a link at the top of the jakarta sidebar menu. I am
confident people will find things to improve but you've got to start
somewhere.
This is CVS. We can revert if need be.

At 07:41 AM 9/4/2003 -0500, Glenn Nielsen wrote:
+1 But wait until the sessions are available at www.apachecon.com

Ceki Gülcü wrote:
Hello everyone,
Apachecon 2003 will take place in Las Vegas, Nevada, USA, 16-19
November 2003.
For this event to be the success that it deserves to have, we need to
make an effort to publicize it as much as possible.
I have created a series of icons that one can use to link to
http://www.ApacheCon.com. The icons are available at
  http://www.apache.org/~ceki/ac2003/
We should at least add a salient image on the sidebar of the jakarta
pages.
Comments?
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 See you in November at ApacheCon US 2003 in Las Vegas.
 http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership.  In fact they probably most definitively disagree with
everything espoused in the above email.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 See you in November at ApacheCon US 2003 in Las Vegas.
 http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Publicizing ApacheCon 2003

[Ceki Gülcü]

If I am not mistakem, early-bird registration seems to be already over...

Anyway, I added a link at the top of the jakarta sidebar menu. I am 
confident people will find things to improve but you've got to start somewhere.

This is CVS. We can revert if need be.

At 07:41 AM 9/4/2003 -0500, Glenn Nielsen wrote:
+1 But wait until the sessions are available at www.apachecon.com

Ceki Gülcü wrote:
Hello everyone,
Apachecon 2003 will take place in Las Vegas, Nevada, USA, 16-19
November 2003.
For this event to be the success that it deserves to have, we need to
make an effort to publicize it as much as possible.
I have created a series of icons that one can use to link to
http://www.ApacheCon.com. The icons are available at
  http://www.apache.org/~ceki/ac2003/
We should at least add a salient image on the sidebar of the jakarta
pages.
Comments?
--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 See you in November at ApacheCon US 2003 in Las Vegas.
 http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Publicizing ApacheCon 2003

[Ceki Gülcü]

Hello everyone,

Apachecon 2003 will take place in Las Vegas, Nevada, USA, 16-19
November 2003.
For this event to be the success that it deserves to have, we need to
make an effort to publicize it as much as possible.
I have created a series of icons that one can use to link to
http://www.ApacheCon.com. The icons are available at
  http://www.apache.org/~ceki/ac2003/

We should at least add a salient image on the sidebar of the jakarta
pages.
Comments?

--
Ceki Gülcü
 For log4j documentation consider "The complete log4j manual"
 ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
 See you in November at ApacheCon US 2003 in Las Vegas.
 http://apachecon.com/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

The Rules of Open-Source Programming

[Ceki Gülcü]

Here are some OSP rules that might be of interest:

  http://www.advogato.org/article/395.html

Enjoy!

--
Ceki  For log4j documentation consider "The complete log4j manual"
  ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Sun

[Ceki Gülcü]

At 10:08 AM 5/28/2003 +0200, you wrote:
On 28/05/2003 9:47 Pier Fumagalli wrote:

Going back and looking at the past 5 years, actually, I think that in this
case, the guy from Sun actually has a point (Rudy? Who the hell is he?).
Oddly enough in the J2EE/JBoss saga, I don't see Sun as being the "bad" guys
(but ok, some of us and Mark go back A LONG time)...
I concur that. The JBossGroup is playing a very tricky game, and some of 
what they do will reflect bad upon the entire Open Source community. Rest 
assured that Werner knows about these tricks since he was involved with 
JBoss in Europe from the beginning. I'm not a Fleury fan, neither, and his 
latest acts (the whitepapers, trying to lure committers into a commercial 
liaison with JBG) have confirmed my feelings.
Don't you think JBoss' huge success has something to do with Sun's
animosity? Every developer I know who has a say on the platform uses
JBoss: better product, better documentation, better support, lower
price.
Do you think Sun Microsystems cares one bit about the well being of
Open Source? The fact that Sun is actively trying to scuttle a
successful OS project, JBoss in this case, is very disturbing.

--
Ceki  For log4j documentation consider "The complete log4j manual"
  ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Sun

[Ceki Gülcü]

At 08:47 AM 5/28/2003 +0100, you wrote:
On 28/5/03 0:26 "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:

> Good: http://www.theserverside.com/home/thread.jsp?thread_id=19500

Hm...

> Evil:
> http://www.shiftat.com/blog/page/werner/20030527#sun_reaffirms_no_jboss_at
Indeed... Mark Fleury _is_ evil.
He has a character but evil? A bit harsh no?

   Pier
--
Ceki  For log4j documentation consider "The complete log4j manual"
  ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PMC VOTE] PMC Nominations

[Ceki Gülcü]

Hi Robert,

I think Mark's nomination follows the sprit set by Sam's initial note.
http://marc.theaimsgroup.com/?l=jakarta-general&m=104275438831116&w=2

As such, I don't see a need for a separate vote.


At 22:16 19.02.2003 +, you wrote:

hi ceki

wouldn't it be less confusing to have a separate vote for mark?

while i'm thinking about it, is general or pmc the right place for votes 
of this kind?

- robert

On Wednesday, February 19, 2003, at 09:15 PM, Ceki Gülcü wrote:

At 19:26 13.02.2003 -0500, you wrote:

Charles Burdick wrote:

Selection criteria aside, I nominate Morgan for the PMC.
Now that I think of it, let me just skim through the
Jakarta-Announcements archive from various points last year.
 - Danny Angus
 - Peter Carlson
 - Morgan Delagrange
 - Pier Fumagalli
 - Ceki Gülcü
 - Dmitri Plotnikov
 - Phillip Rhodes
To add to the list, I'd like to nominate these active committers:
 - James Strachan
 - Jason van Zyl
 - Ted Husted
 - Rod Waldhoff


+1

I'd like to add Mark Womack to the list of candidates.


- Sam Ruby


--
Ceki

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PMC VOTE] PMC Nominations

[Ceki Gülcü]

At 19:26 13.02.2003 -0500, you wrote:

Charles Burdick wrote:

Selection criteria aside, I nominate Morgan for the PMC.
Now that I think of it, let me just skim through the
Jakarta-Announcements archive from various points last year.
 - Danny Angus
 - Peter Carlson
 - Morgan Delagrange
 - Pier Fumagalli
 - Ceki Gülcü
 - Dmitri Plotnikov
 - Phillip Rhodes
To add to the list, I'd like to nominate these active committers:
 - James Strachan
 - Jason van Zyl
 - Ted Husted
 - Rod Waldhoff


+1

I'd like to add Mark Womack to the list of candidates.


- Sam Ruby


--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PMC Nomination

[Ceki Gülcü]

At 15:41 19.02.2003 -0500, you wrote:

Geir Magnusson Jr. wrote:

Shouldn't it be that a committer has been around for a reasonable amount 
of time?  How else would they be a committer?

From the perspective of other ASF projects (e.g., HTTPD), Jakarta gives 
out committer-ship like candy.  With HTTPD, a track record of 
approximately six months of sustained patches is required to become a 
committer.

By contrast HTTPD, by Jakarta standards, gives out PMC membership and ASF 
membership like candy.

I want to strike a happy balance.  I don't necessarily want to slow down 
the rate at which people become committers.  But I would like to see 
significantly more Jakarta committers become PMC and ASF members.

+1

By the way, when are the next membership nominations?


- Sam Ruby


--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Licensing again.

[Ceki Gülcü]

At 07:21 12.02.2003 -0500, Sam Ruby wrote:


LGPL has special rules for 'link'.  What exactly is the concept of a 
'link' in Java?  If A imports B and A and B are not in the same Java 
package (but perhaps share some similar names in the first three 
qualifiers) are they in the same 'library' or not?

Indeed, reading the LGPL does not give a clear answer. Thank you for 
pointing out the heart of the issue.

Java has been around for some time, and you would think that this would 
some clarification of how these concepts map to Java would have been 
provided.  Can we read something into the fact that it has not?

If you chose to. However, if would be better not to read anything into that 
fact.

More importantly would you be willing to risk the value of your reputation 
and some important software assets on the chance that a jury of 12 people 
would agree with what we decided to assign to the meaning of terms used in 
the LGPL license?

It depends on the formulation of the license. In the case of LGPL, I would 
certainly not want to take that risk.

It is not up to the ASF to define what the FSF means when they say 'link' 
and 'library' in the context on Java.

No, it is not up to the ASF. However, has the ASF attempted to clarify the 
matter with the FSF? Why not ask the FSF if importing java classes is 
considered as "derivative work" or simply as "work that uses the library"?

In the absence of a clear response from the FSF, there is no doubt that it 
is safer to shy away from LGPLed code.

I urge all Apache members and committers to carefully follow licensing
related discussions. The matter is too important to be blindly
deferred to the wisdom of the board. Think a little on yourself. Read
the BSD license. Understand its sprit. Read the Apache license. See
how much or how little it differs.


I would encourage general discussion of this on [EMAIL PROTECTED] This 
topic has a much wider applicability than Jakarta.

Sure.


- Sam Ruby


--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Licensing again.

[Ceki Gülcü]

I echo Andrew's reservations. The reasons behind the restriction of
LGPLed imports are unclear and apparently undocumented. Such a crucial
matter deserves to be properly documented. If the restriction cannot
be justified, then it should be lifted.

I urge all Apache members and committers to carefully follow licensing
related discussions. The matter is too important to be blindly
deferred to the wisdom of the board. Think a little on yourself. Read
the BSD license. Understand its sprit. Read the Apache license. See
how much or how little it differs.

At 10:30 09.02.2003 -0500, Andrew C. Oliver wrote:

I'd like to state my preference that this ASF policy be changed in the 
near future.  I prefer to be able to collaborate freely with other 
opensource developers.  I find this policy needlessly obstructs this 
abillity.  I understand that IBM and Sun (referring to Sam's earlier 
explanation) have a compelling coporate interest in being able to create 
commercial forks of Apache's products, however introducting LGPL 
dependencies does not prevent this, it only prevents them from forking 
that dependency.  If that were a problem, them having to create a new 
proprietary edition of that dependency is prefferable in my opinion to the 
Opensource developers having an arbitrary barrier to collaboration.

-Andy



This following is to the best of my understanding, and as simply as I 
know how to state it:
There is no reason that ibiblio cannot distribute L/GPL binaries, subject 
to the conditions of those licenses.  There is no reason why such 
binaries can not be placed there by ASF personnel.  Depending on the 
license, similar statements can be made about other binaries from various 
sources.
It is ASF policy at this time that the runtime of any ASF codebase may 
not involve the Java import of any L/GPL code.  This is to be interpreted 
as the transitive closure of imports: if A (ASF) imports B (non ASF) 
which imports C (L/GPL), then A is in violation of this policy.  Compile 
time only dependencies (like running Checkstyle on POI) are not an issue, 
though I would encourage everybody to make such dependencies purely optional.
The reasons behind this policy involve on an appreciation of the needs of 
people who wish to include ASF code in proprietary and commercial 
products.  Being able to serve such a wide audience is a core value of 
the ASF.  This advice is based on Roy and others having sought after and 
obtained legal advice and council.  I am aware that Brian and others have 
been working to resolve this for some time, but I have no expectation 
that this will be resolved soon.
I hope this makes things clearer.  I am copying board@apache in order to 
solicit clarifications and/or corrections.  If you do not hear of any 
such changes in the next few days, please treat this as official ASF policy.
- Sam Ruby

--
Ceki 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Logging strategy

[Ceki Gülcü]

At 11:21 29.01.2003 +0100, Dani Estermann wrote:

Has jakarta got a strategy/guideline/regulation that recommends a certain 
logging api to be used by jakarta projects? Are existing and future 
jakarta projects allowed to choose between log4j, LogKit, commons-logging 
or even JDK1.4-Logging?

We are currently choosing a logging api and implementation to be used 
in  our business projects. While I favor the power of the log4j 
implementation, I ask myself if it would be wise to use a -- maybe more 
future-proof -- thin bridge like commons-logging on top.

I believe log4j is here to stay. Its user base is large and
growing. As time passes, more people will gravitate to it as it keeps
improving. We have enough cool features in pipe to keep us busy for
the foreseeable future. Simile, the future is bright and open!


Daniel


--
Ceki



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT] Pointedly Extreme Programming

[Ceki Gülcü]

This one surely will become a classic:

http://www.unitedmedia.com/comics/dilbert/archive/dilbert-20030109.html


--
Ceki



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

Re: Short Apache licence for source files

[Ceki Gülcü]

At 07:40 09.12.2002 -0500, James Taylor wrote:

> >- things being 'easier' when being a member: of course not, and I hope
> >that wasn't the impression that I gave
>
> The message I was trying to get across was that the "firewall"
> a.k.a. barrier between members and committers exists mostly in
> people's minds. Membership is not much more than a recognition of
> one's work plus a stamp of approval for being "usually reasonable."
> Think of membership as even more positive karma in slashdot. From the
> Foundations perspective membership also entails responsibilities and
> obligations but that's a different topic.

It is a real barrier in that things seem less opaque for members. You
can tell people that nothing important happens on the members only
lists, but as long as there _are_ members only lists and such, the
firewall will always be percieved.


Many things remain opaque for members because new members do not
suddenly become omniscient. The phenomena of community legends exists
within Apache as within any community with some history. What sets
Apache apart from other communities is its built in open and tolerant
nature.  Openness is a hard term to define. IMO, the ability to speak
up and argue on almost any matter without fear of retribution makes
Apache open.

You will not find a single member claiming that important business is
conducted on the members list. The argument of members only mailing
lists preventing committers from gaining access to important
information does not hold water unless one assumes that all ASF
members are irredeemable liars united in a conspiracy against the poor
committers.

Some say that perception is everything. If perception is everything,
then reason and truth do not matter.  As far as I am concerned, reason
and truth are everything with perception a distant contender. After
all, we all perceive the earth to be flat which does not make the
earth any less spherical.

What is great about Apache is that a good argument and some
perseverance will get you a long way. That is a fact.  Status matters
but less than one would imagine. My disappointment with Apache was
that occasionally you get a very persistent person who convincingly
promotes bad ideas. Although some may see that and not agree, they
eventually throw in the towel. It then takes the community months or
even years to realize that the idea was bad. Of course, the problem
does stem from the open nature of the ASF but rather from the
imperfections of *any* conceivable system. The bottom line is that we
should not mistake the failings of the system with our own PGL
syndrome (paranoia, greed and laziness).


-- jt, observing not complaining.


--
Ceki, expounding not accusing.




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

Re: Short Apache licence for source files

[Ceki Gülcü]

At 12:23 09.12.2002 +0100, Steven Noels wrote:

Ceki Gülcü wrote:

- things being 'easier' when being a member: of course not, and I hope 
that wasn't the impression that I gave

The message I was trying to get across was that the "firewall"
a.k.a. barrier between members and committers exists mostly in
people's minds. Membership is not much more than a recognition of
one's work plus a stamp of approval for being "usually reasonable."
Think of membership as even more positive karma in slashdot. From the
Foundations perspective membership also entails responsibilities and
obligations but that's a different topic.






--
Ceki



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Short Apache licence for source files

[Ceki Gülcü]

At 20:27 07.12.2002 +0100, you wrote:

Pier Fumagalli wrote:


You're free to file your complaint to the appropriate department dealing
with those kinds of issues: 


Naaah. There's a difference between making a remark here when the 
opportunity is there, and starting another 'feeding the trolls' thread 
over at [EMAIL PROTECTED]

I now see that my remark has been duly noted, and I can only hope that it 
somehow penetrates the firewall between us and The Members.

I think the tradition of meritocracy is deeply rooted in our
collective consciousness; I mean that of Apache. If you knock on the
door of [EMAIL PROTECTED], I am sure you will be allowed in. Things
do not necessarily become easier as a member, one still has to work on
listening, understanding and persuasion, exactly the same way a
a "committed" committer would.

Send an email to [EMAIL PROTECTED] and see how you are
received. Note the CC: to licensing@.




--
Steven Noelshttp://outerthought.org/


--
Ceki



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

Re: Short Apache licence for source files

[Ceki Gülcü]

At 05:52 05.12.2002 -0500, Sam Ruby wrote:

Ceki Gülcü wrote:

Would a shut-up-and-think-for-yourself be any better?  It seems to me that 
you are seeking an explicit sanction for the practice of using the current 
license by reference.

Yes, shut-up-and-think-for-yourself would be better assuming it came
with at least a hint for the reasons behind the policy. Until very
recently, I could not find any explanation for the reasons behind the
policy beyond "*someone* on the board said so, now please go
away". Moreover, when we submitted this question to the board the
answer was far from clear-cut, although that may be due to a
misunderstanding on my part.


The ASF is very much centered around an open and pragmatic license.  If 
you want to weaken this a bit in the name of saving a few bytes, the ASF 
is not going to falter and fold.

I never expected the ASF to falter and fold. However, I do expect the
ASF to act reasonably which implies that it can explain/document its
decisions. Is that too much to ask for?

By the way, I am not seeking a sanction. I am trying to understand.


At the moment, this may be the closest thing to a sanction you may 
get.  If a better one becomes available, I'll be sure to forward it on.

You know where to reach me.


Peace.


Acked and mirrored.


- Sam Ruby


--
Ceki



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Short Apache licence for source files

[Ceki Gülcü]

At 16:14 04.12.2002 -0800, Craig R. McClanahan wrote:


In the mean time, I believe all Apache projects should treat the Board
member comments quoted above and elsewhere in this thread (and taken out
of much larger discussions) as authoritative direction to ASF committers
that we should use the long form of the ASF 1.1 license in every source
file checked in to Apache CV repositories.

It doesn't matter whether it's legally required (to get around the "this
software" interpretation) or not.  It matters that the ASF Board
(representing the foudnation, which is the owner of all this code) told us
to do it that way.  That's all the reason any of us should need.


I thought that we were also supposed and even encouraged to think for
ourselves. No one has suggested to defy the board. I resent the shut-
-up-and-do-as-you-are-told attitude which does not characterize you,
the ASF, nor anyone on the board. What is going on here?


Craig McClanahan


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



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

Re: Short Apache licence for source files

[Ceki Gülcü]

At 07:31 04.12.2002 -0500, Sam Ruby wrote:

Stefan Mainz wrote:

Ceki Gülcü wrote:


I do not understand what Roy means by "the scope of what was covered
beyond 'this file'" Copyright law only protects the expression of an
idea, so I am baffled by what is meant by the scope beyond the file,
that is the written expression of the software developer. How can
copyright law apply to anything beyond the file?

Propably i am not the right person to answer this (not being a lawyer), but:
If you refer to a file which includes the license and the license says
_this file_ the license applies to the license file, not the onw which 
referes to the file.

IANAL either.  My understanding matches Stefan's above.  If you include 
the current license by reference, the ASF appears to be well protected, 
but you may not be achieving what you want.  People who make use of the 
code you produce may some day be surprised to find that the only thing 
they actually have permission to make use of is the LICENSE FILE itself, 
subject of course to the terms contained therein.

OK, I think I understand slightly better but our license refers to
"this software" not to any specific file.

I think we all agree that referring to the license means that the
terms of the license apply, at least that is the intention.

There are three possible cases.

1) Bad faith interpretation

Someone decides that the license applies to the license file itself
and not to other files. If the license does not apply, then that
someone does not have the legal right to copy our software.

I think this is the case Roy was referring to in his comments -- the
comments I forwarded earlier without permission.

2) Good faith but cautious interpretation

In this case, someone is worried that the license applies to the
license file itself but not to other files. Thus, he or she decides
not use our software for fear of violating copyright law. Isn't this a
bit farfetched? Couldn't we address this concern in the license FAQ?

3) Intended interpretation

The Apache license applies even by reference as intended. No problems there.


The next license is intended to fix this.


Could we say referring to the license 1.1 is not recommended practice
but doing so does NOT make you a bad citizen?


- Sam Ruby


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Short Apache licence for source files

[Ceki Gülcü]

At 12:02 04.12.2002 +0100, Stefan Mainz wrote:

Ceki Gülcü wrote:


I do not understand what Roy means by "the scope of what was covered
beyond 'this file'" Copyright law only protects the expression of an
idea, so I am baffled by what is meant by the scope beyond the file,
that is the written expression of the software developer. How can
copyright law apply to anything beyond the file?



Propably i am not the right person to answer this (not being a lawyer), but:

If you refer to a file which includes the license and the license says
_this file_ the license applies to the license file, not the onw which 
referes to the file.

I am not sure I understand.

In our particular case, that is the Apache Software License version
1.1, the license talks about "this software" not about any specific
file.

Source: http://www.apache.org/LICENSE and
   http://www.apache.org/foundation/licence-FAQ.html

The copyright notice + reference text we are talking about has the
form:

/*
 * Copyright (C) The Apache Software Foundation. All rights reserved.
 *
 * This software is published under the terms of the Apache Software License
 * version 1.1, a copy of which has been included  with this distribution in
 * the LICENSE.txt file.
 */

How could the situation you mention arise in our case?


Stefan


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Short Apache licence for source files

[Ceki Gülcü]

At 12:13 04.12.2002 +0100, you wrote:



Ceki Gülcü wrote:

At 11:06 04.12.2002 +0100, Nicola Ken Barozzi wrote:


IANAL and not the one to decide.
IIRC IIUC the board, &&|| board members have said to use the full 
version till version 2.0 arrives.
Well, as far as I know, there is no permission to use a reference to
the license although there is no explicit prohibition either.


You mean that everything can be done if it's not prohibited explicitly?
Come on, what's this, a policed community?



I was trying to convey that the word "should" has different meanings. It
can be interpreted as a recommendation or alternatively as an
obligation. For example,

1) One should brush one's teeth. Otherwise, you'll get bad
teeth. However, not brushing your teeth does not make you a bad
citizen.

2) One should be respectful of others. Being disrespectful or violent
makes you a bad citizen.

In 1) SHOULD is a recommendation whereas in 2) SHOULD really means MUST.

Thus, in the sentence, "we should use include the license in each
file," does SHOULD mean MUST or is it just a recommendation?


You are free to take my word for it, or if you deem it necessary, go ask 
directly and eventually report back.
Michael A. Smith actually went to the board a few weeks ago. I did not
see a closure. As long as an ASF official (board, PMC) does not
officially take a position on this, or until there is an official
document on this topic, one should not make absolute affirmations.


My words: "Currently we should use the full version."


Should or must? :-)


To stop this once and for all, since it seems that having a short license 
is very important for some (still don't know why), I've sent a request for 
clarification to the board too.

The license (version 1.1) is 41 lines long whereas the copyright notice 
plus the reference to the license is just 7 lines.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Short Apache licence for source files

[Ceki Gülcü]

At 10:43 04.12.2002 +0100, Martin van den Bemt wrote:


As was said : it is simply not allowed by the board.


I do not mean to offend anyone, but hearsay is not good enough. As
long as an ASF official (board, PMC) does not officially take a
position on this, or until there is an official document on this
topic, one should not make absolute statements.

Yes, it is theoretically safer to include the license in each file, but
including a copyright notice followed by reference to the license
should be good enough (because it makes sense.)


Mvgr,
Martin


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



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

Re: Short Apache licence for source files

[Ceki Gülcü]

At 11:06 04.12.2002 +0100, Nicola Ken Barozzi wrote:


IANAL and not the one to decide.
IIRC IIUC the board, &&|| board members have said to use the full version 
till version 2.0 arrives.

Well, as far as I know, there is no permission to use a reference to
the license although there is no explicit prohibition either.


You are free to take my word for it, or if you deem it necessary, go ask 
directly and eventually report back.

Michael A. Smith actually went to the board a few weeks ago. I did not
see a closure. As long as an ASF official (board, PMC) does not
officially take a position on this, or until there is an official
document on this topic, one should not make absolute affirmations.


--
Nicola Ken Barozzi   [EMAIL PROTECTED]


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



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

Re: Short Apache licence for source files

[Ceki Gülcü]

At 07:54 04.12.2002 +0100, Nicola Ken Barozzi wrote:

Currently we should use the full version.
There will be a short version of the next 2.0 license that will be equally 
protecting from a legal POV, but in the meantime use the full version.

Why? What is wrong with a copyright notice followed by a reference to
the license? The whole world does it. Why shouldn't we?


--
Nicola Ken Barozzi   [EMAIL PROTECTED]



--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



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

Re: Short Apache licence for source files

[Ceki Gülcü]

Given that for works published after March 1, 1989 it is not even
necessary to place a copyright notice to benefit from copyright law
protection, I do not see why the long form is absolutely
necessary. Moreover, the next version of the Apache Software License
will specifically allow the short form. It may be slightly better to
include the whole license in certain obscure circumstances but that
does mean that the reference to the license (a.k.a. the short form) is
useless and that it should be disallowed.

Here is what Roy Fielding had to say on the subject. I am quoting
without explicit permission hoping that he will not mind. :-(



  > and inclusion by reference isn't suddenly becoming official with the
  > 2.0 licence; until we hear counsel that says its safe, we most likely
  > won't permit it regardless of the size of the licence text.

  WTF?  Of course it is safe, and we've already had several lawyers
  review it, not to mention ample evidence from the MPL and GPL that
  other lawyers believe it is safe with the proper reference text.  The
  proposed 2.0 license text was specifically written to support
  inclusion by reference.

  The problem with the 1.1 license is that it lacked a way to define the
  scope of what was covered beyond "this file".  As such, the board has
  not approved its use by reference for our own products.

  Even so, it is still "safe" (albeit confusing) to use it by reference
  provided that the file starts with a proper copyright line and
  "All rights reserved."  After all, our license simply spells out the
  conditions under which we reduce our own rights -- it doesn't matter
  whether or not the user can see the full agreement because without
  the agreement they cannot legally copy the file at all.

  Roy



I do not understand what Roy means by "the scope of what was covered
beyond 'this file'" Copyright law only protects the expression of an
idea, so I am baffled by what is meant by the scope beyond the file,
that is the written expression of the software developer. How can
copyright law apply to anything beyond the file?

Anyway, in the last paragraph Roy makes it clear that without the
licence the software cannot be legally copied. Thus, asserting the
Apache copyright in each file and referencing the Apache Software
License should be sufficient to protect our copyright.

What am I missing? Was there ever a closure to this question?



At 08:48 04.12.2002 +0100, you wrote:

On Wed, 4 Dec 2002, Darrell DeBoer <[EMAIL PROTECTED]> wrote:

> I don't know where it started, but if someone can someone tell me
> definitively that this is against ASF rules, I will move to rectify
> the situation.

Roy Fielding and several other board members have repeatedly stated
that the short version is not acceptable IIRC.  License 2.0 is
supposed to help.

Stefan

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


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



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

Re: Gump changes

[Ceki Gülcü]

The Gump setup can be leveraged as a testing lab. I found the fact
that gump runs on machines in different timezones (at least in a
different timezone than mine) very valuable. This small difference has
allowed us to catch a timezone dependent bug  which we might
not have caught otherwise.

Runs on different JDKs, XML parsers, etc. adds to the testing lab
functionality of the current gump deployments (note the plural).

The above applies to junit tests not to formal compilation problems.

At 08:26 12.11.2002 -0500, Sam Ruby wrote:

Pier Fumagalli wrote

So I'm wondering why the heck I'm running that thing 4 times a day,
if at the end, no one uses it...


It should only be run on Nagoya twice a day.  As a general rule, builds 
have the most success on a Linux/intel machine, so that's the one that I 
call the "official" one.

It is very helpful to have gump run more than once a day so that people 
who are making changes that they don't *think* will impact others have an 
opportunity to verify this before all sorts of nag messages go out.

So, gump runs every 6 hours spread across 3 machines.

- Sam Ruby


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


--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



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

Re: Differences between Structs and Turbine ???

[Ceki Gülcü]

At 12:07 08.10.2002 -0700, Jon Scott Stevens wrote:

>I recently spent a couple weekend nights and built the StudioZ.tv website in
>PHP4 on OSX. It is a pretty cool webapp that has really transformed things
>for us and made my life MUCH easier (the office staff can fully manage the
>events that show up on the website via a browser). I incorporate several
>technologies into the site (including a cool XML-RPC interface that talks to
>presaleticketing.com to tell us how many tickets have been sold). I used PHP
>because it was quick and easy and I didn't have time to 'design' the
>application.
>
>The only thing that sucks is that the code is a complete hack that is going
>to be terrible to maintain over the long term and half the time, I can't
>figure out why something does or doesn't work.

It is surprising that a Java expert with monumental contributions to
this community would not use Java technology to create his website. Is
this a case of "do as I say, not as I do"?

Of course one is free to try new approaches but the anecdote is still quite
telling. Cool-looking site by the way.

>=)
>
>-jon
>
>--
>StudioZ.tv /\ Bar/Nightclub/Entertainment
>314 11th Street @ Folsom /\ San Francisco
> http://studioz.tv/

--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



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

log4j-dev@ summary for June

[Ceki Gülcü]

Rob,

Thank you for the Jakarta Newsletter initiative. I am looking forward to 
the June issue.

Here is the log4j submission.

This file contains the summary of what has been discussed on the
log4j-dev@ mailing lists. Its monthly contents are sent to the editor
of the Jakarta Newsletter. For the first issue of the Jakarta
Newsletter see:

   http://marc.theaimsgroup.com/?l=jakarta-general&m=102328546509220&w=2

+==+
|June 20002|
+==+

The month started with a question by John Armstrong [1] on whether
log4j offered any guarantees on binary compatibility between various
versions.  To which Ceki replied by stating [2] the current policy of
not removing deprecated methods until at least two release cycles are
completed. This reply did not seem to satisfy John Armstrong and a
long discussion ensued. A historical perspective [3] seemed to satisfy
most people, at least the discussion petered off.

[1] http://marc.theaimsgroup.com/?l=log4j-dev&m=102335790906496&w=2
[2] http://marc.theaimsgroup.com/?l=log4j-dev&m=102336327109965&w=2
[3] http://marc.theaimsgroup.com/?l=log4j-dev&m=102387540521717&w=2

Mike Agnus started [4] a discussion about timezone and locale related
issues in log4j date formats. James Cakalic and Mike discussed the
importance of the decimal character separator.  Possible performance
improvements were also suggested. Mark Womack submitted code for
timezone support for date elements of pattern layout. Unfortunately,
the code was anonymous and we could not take into consideration.  The
idea seemed to catch on though.

[4] http://marc.theaimsgroup.com/?l=log4j-dev&m=102209832808942&w=2
[5] http://marc.theaimsgroup.com/?l=log4j-dev&m=102420694310844&w=2

Ceki asked for clarifications [6] on java buffered IO because his
experience did not match the myth. Georg Lundesgaard mentioned [7] the
character conversion buffering aspect as explained in the
OutputStreamWriter javadocs.

[6] http://marc.theaimsgroup.com/?l=log4j-dev&m=102326443025158&w=2
[7] http://marc.theaimsgroup.com/?l=log4j-dev&m=102327620700816&w=2

Costin Manolache related his experience [8] with configuring log4j
with JMX. He mentioned the web-application logging insulation
problem. In response, Ceki wrote a specification [9] for solving the
logging separation problem. This was followed by a promising
discussion [10] on Tomcat-dev.

[8]  http://marc.theaimsgroup.com/?l=log4j-dev&m=102412323003656&w=2
[9]  http://qos.ch/containers/sc.html
[10] http://marc.theaimsgroup.com/?t=10251038101&r=1&w=2

Mark made a proposal [1]] for a new log4j component called "Receiver."

[11] http://marc.theaimsgroup.com/?l=log4j-dev&m=102523926310678&w=2


--
Ceki


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

Re: welcoming and nurturing volunteers

[Ceki Gülcü]

At 10:07 25.05.2002 -0400, you wrote:
>Ceki Gülcü wrote:
> >
> > The motivational power of appreciation cannot be underestimated. The
> > author is correct in emphasizing the point. What is not emphasized
> > enough is the need for direction. What's the use of having a million
> > volunteers if they all pull in different directions?
>
>Apache projects tend to attract an abundance of leaders.

I was not thinking of Apache or Jakarta.  My reading of the
article was "if you make your volunteers warm and cozy everything will
be fine" which is just wishful thinking.  I admit that this is an
incomplete reading of the Sean Haugh's article given that the issue of
leadership and direction is implied throughout the article--the
keyword here is "implied".

>- Sam Ruby

--
Ceki


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: welcoming and nurturing volunteers

[Ceki Gülcü]

At 23:30 24.05.2002 -0400, Sam Ruby wrote:
>http://www.libertyforall.net/2002/archive/do-ocracy.html

The motivational power of appreciation cannot be underestimated. The
author is correct in emphasizing the point. What is not emphasized
enough is the need for direction. What's the use of having a million
volunteers if they all pull in different directions?

>- Sam Ruby

--
Ceki


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

Re: Criteria for commit access

[Ceki Gülcü]

At 18:31 24.05.2002 -0400, Sam Ruby wrote:

>* Perhaps a more fruitful topic for us to explore is when to retire
>committer status due to inactivity.  Pier is one of the few to do this
>explicitly.  I have done it a bit more implicitly - including submitting
>patches to projects that I am officially a committer to.


I find that submitting a patch and let someone else apply it to
projects where you are active (and a committer) has several
advantages.

It says: "hey look what I have created. What do you think?"
Submitting a patch is more likely to elicit active comments.

It is also a sign of respect. You know you can do it. The other
developers know you can do it; but by not doing it you encourage the sense
ownership of another developer (the one who will apply the patch) for
that part of the code where the patch will go.

Obviously, this sort of dancing becomes unnecessary when you have a
close and trusting relationship with the other developer(s) although
establishing trust takes time. It does not happen overnight.

>- Sam Ruby

--
Ceki

ps: By the way, the idea of submitting a patch as a committer is not
mine. It's yours (Sam's).


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

Re: Criteria for commit access; was: [VOTE] New Committer Dan Sandberg

[Ceki Gülcü]

At 10:07 24.05.2002 -0700, [EMAIL PROTECTED] wrote:
>On Fri, 24 May 2002, Andrew C. Oliver wrote:
>
> > Personally, I feel this discussion belongs solely on the tomcat list and
> > is up to the committers of Tomcat to resolve.  If the Tomcat community
> > feels the bar should be raised, let them raise it.  If they do not, then
> > it shall not be raised.  I don't feel it should be up to anyone else.
>
>I CC: general because the PMC was on the Cc:
>
>I think any discussion that is related with the PMC should be on general.
>( except exceptions ).
>
>It seems the request to raise the bar comes from the 'members', at least
>that's what I can conclude from Pier's mail - and thus is of general
>interest.

Absolutely.

It is crystal clear that the decision to grant committer access to a
project lies solely with the project itself, not the PMC nor the ASF
board. (I mean "project" in the Ant, Avalon sense, not the
Jakarta sense.)

Having said this, there is nothing wrong with discussing criteria for
proposing committers. In a conversation I had with Stefano Mazzocchi a
long time ago, he outlined the reasons for his liberal policy (for
granting commit access). I tend to oscillate between a liberal policy
and a conservative one.  A discussion on this topic is very well deserved imho.


>Costin

--
Ceki

ps: The tomcat developers should complete the vote on Dan's
candidacy. His candidacy should not be hostage to this discussion.


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

Re: bugzilla related emails

[Ceki Gülcü]

At 09:32 16.05.2002 +0200, Stefan Bodewig wrote:
>On Thu, 16 May 2002, Ceki Gülc <[EMAIL PROTECTED]> wrote:
>
> > The log4j developers would like log4j bug report related emails to
> > also appear on the log4j-dev mailing list. Can this be done?
>
>All that needs to be done is changing the default owner for the
>components (which means you wouldn't be getting the reports to your
>personal address any longer).  I don't know whether it is possible to
>define automatic CCs in addition to default owners.
>
>Do you have enough karma to change the default owner of the Log4J
>components?  If not, I can do that for you.

In fact I have enough karma. I just did the change you suggested. The
only glitch was that the password for log4j-dev goes to
[EMAIL PROTECTED] Fortunately,
[EMAIL PROTECTED] is not subscribed to itself such that the
list moderators could intercept the password before it got public.

By the way, thanks for your prompt offer for help.

>Stefan

--
Ceki


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

bugzilla related emails

[Ceki Gülcü]

Hello,

The log4j developers would like log4j bug report related emails to
also appear on the log4j-dev mailing list. Can this be done?

Sorry for the noise, I am just trying to follow the instructions found
at http://jakarta.apache.org/site/bugs.html:

   Pier Fumagalli has set up the Apache Bug Database. Please use this
   database report bugs and suggest new features. To suggest a new
   feature, set the severity of the bug to "enhancement". In case of
   problems with the Apache Bug Database, please notify
   [EMAIL PROTECTED]

Thanks in advance, Ceki


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

Re: [New Subproject Proposal] ObjectBridge

[Ceki Gülcü]

Here is my enthusiastic but non binding +1.

At 14:41 29.04.2002 -0400, you wrote:
>Hi,
>
>I would like to propose ObjectRelationalBridge
>(http://objectbridge.sourceforge.net/) as a top level subproject of
>Jakarta.

--
Ceki


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

Re: Large code donation?

[Ceki Gülcü]

At 00:07 13.04.2002 +0200, [EMAIL PROTECTED] wrote:

>On Fri, 12 Apr 2002, Ceki [iso-8859-1] Gülcü wrote:
>
> > The results of a recent vote show that the log4j community has strong 
> interest
> > in the donation. Is there  a document that I can present to the donator for
> > signature?
> > I assume this document is NOT the Contributor License Agreement because
> > that document  applies to individuals, not corporations. Correct? To 
> whom do I
> > (or the donator) send the signed document? Thanks in advance, Ceki
> >
> > At 23:58 11.04.2002 +0200, [EMAIL PROTECTED] wrote:
> >
> > >There are several reasons why this needs a contributors license (assuming
> > >people want the code)
>...cut...
>
>I think the refence got cut out :-) you want:
>
> cvs.apache.org:/home/cvs/foundation
> software-grant.txt/pdf

D'oh. BTW, there is no software-grant.pdf only .txt.

>Some hints on filling it out:
>
>->  Get the committers all synced up and in agreement (seems
> to be the case) that this is a cool thing they want.

Done.

>->  Make sure your PMC is fine with it.
> (if the committers are fine - usually not an issue! PMC
> tend to worry about licenses and boring things.)

I don't see what the PMC has got to do with this, but OK.

>->  Get the document to the licensor early or in parallel
> so they know what is coming. You may need some extensive
> communication to explain things.

OK.

>->  Notice that most bulk sourced code contains some text like
> "this code started its live as a contribution of Foo Bar.
> etc..". just below the license. You may want to suggest/negotiate
> such a text prior to the grant work.

As I understand it, the donator is not asking for such text. I'll mention
this possibility to the donator just to make sure.

>Once you are ready - put something like a short description of the
>software and something like an md5 or an ls -lR in exhibit A; get it
>signed and have the licensor send it to the secretary; Address, Fax, email
>and phone are all on the web site and in members. We will want a paper
>version at some point.

OK.

>If the licensor wants to be very careful about what is in the exhibit A -
>they of course you can make it more elaborate; add a floppy or CD with a
>signature, etc. The whole point is that it should be reasonably easy to
>establish later what we got and at what point. Use as many pages as you
>need :-).

A dated, signed MD5 hash should provide excellent security in this case.

I think we can handle it from here (famous last words). Thanks again, Ceki

--
Ceki


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

Re: Large code donation?

[Ceki Gülcü]

The results of a recent vote show that the log4j community has strong interest
in the donation. Is there  a document that I can present to the donator for 
signature?
I assume this document is NOT the Contributor License Agreement because
that document  applies to individuals, not corporations. Correct? To whom do I
(or the donator) send the signed document? Thanks in advance, Ceki

At 23:58 11.04.2002 +0200, [EMAIL PROTECTED] wrote:

>There are several reasons why this needs a contributors license (assuming
>people want the code)

--
Ceki


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

Re: Large code donation?

[Ceki Gülcü]

Your explanation is crystal clear. I'll organize a vote on the
donation just to make sure that we really want the code. Thanks again, Ceki

At 23:58 11.04.2002 +0200, [EMAIL PROTECTED] wrote:

>On Thu, 11 Apr 2002, Ceki [iso-8859-1] Gülcü wrote:
>
> > A commercial company, after changing its business orientation, recently
> > proposed to donate a rather large chuck of code, essentially a log4j
> > extension, to the log4j project. Do we need to have them sign any
> > paperwork? Assuming they post the source code (under the Apache Software
> > License)  to the log4j-dev list, can we then consider that the
> > contribution is "just" a large patch?
> >
> > Any clarification on this matter would be greatly appreciated.
>
>There are several reasons why this needs a contributors license (assuming
>people want the code)
>
>-   Whoever post the patch cannot claim he has written
> it himself
>-   And since it is clearly associated with a commercial
> company - that person cannot easily claim he or she
> owns it 100%
>-   Nor do we have a clear relation (committer, member)
> with that person.
>
>So each of those is an indiactor that you propably want to go through the
>contributor license hassle. The PMC or board can help you.
>
>Feel free to ask for a hand.
>
>But of course you do want to make sure that the log4j community
>actually wants that code !
>
>Dw
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

--
Ceki


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

Large code donation?

[Ceki Gülcü]

Hi all,

A commercial company, after changing its business orientation, recently 
proposed to
donate a rather large chuck of code, essentially a log4j extension, to the 
log4j project.
Do we need to have them sign  any paperwork? Assuming they post the source 
code
(under the Apache Software License)  to the log4j-dev list, can we then 
consider that
the contribution is "just" a large patch?

Any clarification on this matter would be greatly appreciated.

--
Ceki


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

RE: Comments on the commons-logging API

[Ceki Gülcü]

At 15:36 29.03.2002 +, Danny Angus wrote:

> > Now that you can (well, soon) legally implement JSR47's, you
> > might was well
> > support their interfaces and semantics, and then 'embrace and
> > extend'.  Just
> > do the JSR47 stuff better :)
>
>Could Log4J now become an RI of JSR47 ? (I'm still not completely clear
>about all this..)

No, it cannot. JSR47 is not an some network protocol or an abstract
description of an interface, coding rules etc. It is a nuts and bolts
implementation.

Jason Hunter also mentioned some rule about being part of the
JDK 1.4 umbrella JSR which apparently changes things. (Don't
ask me why.)


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 18:28 28.03.2002 -0800, you wrote:
>>god no. The avalon group was already using a facade logger long before 
>>commons was for much the same reason commons adopted one.
>
>
>Is Avalon still using its own facade logger or changed to commons-logging?
>
>I'm just wondering: How many Jakarta projects use this common-logging 
>package?  What's the advantage of having a common logging package if it's 
>not widely used even within the Jakarta community?
>
>One solution: all Jakarta projects must support both LogKit and Log4J (as 
>they are both part of the family) by using commons-logging if they want to 
>(but as logging is not the core business of many Jakarta projects, using 
>the common-logging package makes sense).
>
>Another solution : drop one logger (don't shoot me!) and stand beside the 
>winner.  Users willing to use Jakarta projects will *have* to use the 
>Jakarta logger.  Sound M$-ish, doesn't it?
>
>Last solution : everyone stands where they are: pro-choice vs. pro-one-logger.

Your allusion to Microsoft is interesting as much as it is troubling. For 
some reason
everybody here takes the development of good software for granted. It takes 
a lot of
energy and time. We waste much of it bickering among ourselves. Initially I was
very saddened by this but now have grown accustomed to it. I do not expect
to change anyones's mind. I am pretty sick of the politics and have much work
to do.


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

Good point, except that the loop length was 100'000'000 so the cost of the
first 10'000 calls would be dwarfed by the remaining 99'990'000. Of course
there is also:

~/>java Indirect 1
log4j: Parsing threshold string [WARN]
log4j: Could not find root logger information. Is this OK?
log4j: Finished configuring.
Total: 0.0 in microseconds.
Average time: 0.0 in microseconds.

Point well taken nonetheless.

At 22:01 29.03.2002 +1100, you wrote:
>Try changing your code to loop 10,000 times or so before you start the real
>test. This will make sure the JVMs are warmed up and all systems are
>configured properly. That should drop the difference even more in theory.

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

The interesting case is of course measuring performance when logging is
turned off. Here is a little experiment.

My CLASSPATH:

CLASSPATH=.;/java/jdk1.3.1/jre/lib/rt.jar;/home/cgu/ASF/jakarta-log4j-1.2beta4/dist/lib/log4j-1.2beta4.jar;commons-logging-1.0/commons-logging.jar


I have written two short programs that log in a loop. One called
Direct.java log that directly uses log4j. The other, called Indirect.java,
logs indirectly using commons-logging.

-
import org.apache.log4j.Logger;
import org.apache.log4j.Level;

public class Direct {

   public static void main(String args[]) {

 if(args.length != 1) {
   System.err.println("Usage: java Direct runLength\n" +
   "  where runLength is an int representing the run length of loops\n"+
   "I suggest a runLength of at least 100'000.");
 }

 int runLength = Integer.parseInt(args[0]);

 Logger logger = Logger.getLogger("bandicoot");

 // disable all logging below INFO.
 logger.getLoggerRepository().setThreshold(Level.INFO);

 long begin = System.currentTimeMillis();
 for(int i = 0; i < runLength; i++) {
   if(logger.isDebugEnabled()) {
 logger.debug("This is message "+ i);
   }
 }

 long end = System.currentTimeMillis();
 double totalMicros = (end-begin)*1000.0;
 System.out.println("Average time: "+totalMicros/runLength+" in 
microseconds.");
   }
}
---

Here is Indirect.java

---
import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.Log;

public class Indirect {

   public static void main(String args[]) {

 if(args.length != 1) {
   System.err.println("Usage: java Indirect runLength\n" +
   "  where runLength is an int representing the run length of loops\n"+
   "I suggest a runLength of at least 100'000.");
 }

 int runLength = Integer.parseInt(args[0]);

 Log log = LogFactory.getFactory().getInstance("bandicoot");

 // notice that in this example there is no code to set the level
 // of the repository.

 long begin = System.currentTimeMillis();
 for(int i = 0; i < runLength; i++) {
   if(log.isDebugEnabled()) {
 log.debug("This is message "+ i);
   }
 }

 long end = System.currentTimeMillis();
 double totalMicros = (end-begin)*1000.0;
 System.out.println("Average time: "+totalMicros/runLength+" in 
microseconds.");
   }
}
---

Running Direct I get:

~/> java Direct 1
Average time: 0.01903 in microseconds.

Running Indirect I get:

~/> java Indirect 1
log4j:WARN No appenders could be found for logger (bandicoot).
log4j:WARN Please initialize the log4j system properly.
Average time: 1.15155 in microseconds.

That's a factor of 60 and not in percents!

Of course, I cheated because Indirect.java does not configure
the repository threshold.

Placing a file called "log4j.properties" with the following contents

   log4j.threshold=WARN
   log4j.debug=true

in the *current* directory (remember I have '.' as the first entry in
my CLASSPATH) and running Indirect java I get:

~/>  java Indirect 1
log4j: Parsing threshold string [WARN]
log4j: Could not find root logger information. Is this OK?
log4j: Finished configuring.
Average time: 0.02854 in microseconds.

That's an increase of 50, but in percents this time. Interestingly,
enough the results are very similar in JDK 1.2.2; the numbers change
but the proportions don't.

Moral of the story? You are essentially right if the user knows what
she is doing.

It would be interesting to see if changing

  private Category category = null;

to

  final private Category category;

in org.apache.commons.logging.impl.Log4JCategoryLog would
change anything. It would be a nice experiment.

At 12:46 29.03.2002 +1100, you wrote:
>On Fri, 29 Mar 2002 12:38, Ceki Gülcü wrote:
> > 1) logging calls are made thousands of times so the indirection through
> > an equalizer API (like commons-logging) has a performance impact
>
>Not in modern JVMs (read most almost all jdk1.3 impls).
>
>As long as the underlying indirection (ie between commons and Log4j) is done
>via a final variable then the cost is zero due to JVM optimizations. Theres
>still the cost of the dynamic dispatch between user land code and commons
>code but that cost is very very minimal compared to the rest of the logging
>operations.
>
>The cost comes in constructing the string objects (which is literally
>thousands times more expensive than a dynamic dispatch) and routing the log
>message.
>
>As long as the API supports functions like isDebugEnabled() (which I believe
>commons does? or at least did) then the performance cost is so negligable to
>be unimportant.

In one word? Yes.


--
Ceki
My link of the month: http://java.sun.com/aboutJava/st

Re: Comments on the commons-logging API

[Ceki Gülcü]

Wait a minute, I know you... You are the apricot
(http://sourceforge.net/projects/apricot/) guy. In the fairy tale "The
Emperor's new clothes," what was the name of the child who calls

 "He's naked. The man in the crown is naked"

Was it Vladimir Bossicard?


At 18:28 28.03.2002 -0800, you wrote:
>>god no. The avalon group was already using a facade logger long before 
>>commons was for much the same reason commons adopted one.
>
>
>Is Avalon still using its own facade logger or changed to commons-logging?
>
>I'm just wondering: How many Jakarta projects use this common-logging 
>package?  What's the advantage of having a common logging package if it's 
>not widely used even within the Jakarta community?
>
>One solution: all Jakarta projects must support both LogKit and Log4J (as 
>they are both part of the family) by using commons-logging if they want to 
>(but as logging is not the core business of many Jakarta projects, using 
>the common-logging package makes sense).
>
>Another solution : drop one logger (don't shoot me!) and stand beside the 
>winner.  Users willing to use Jakarta projects will *have* to use the 
>Jakarta logger.  Sound M$-ish, doesn't it?
>
>Last solution : everyone stands where they are: pro-choice vs. pro-one-logger.
>
>-Vladimir
>
>--
>Vladimir Bossicard
>www.bossicard.com

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 16:56 28.03.2002 -0800, you wrote:
>On Fri, 29 Mar 2002, Ceki Gülcü wrote:
>
> > I think you have done a pretty good job on the log4j wrapper. However,
> > I am pretty stretched out as it is, so I can't really help with something
> > I don't particularly like. Besides, if people find commons-logging really
> > useful
> > they will build a community around it. What I say or think won't matter.
>
>First, I'm not the author of log4j wrapper - it's Scott Sanders, Rod, etc.
>( to give credits to who deserve :-)

OK, I had meant the whole bunch not just you. :-)

>And what you say, think and do does matter.
>
>In particular maintaining and helping with the log4j wrapper, and making
>sure commons-logging works best with log4j will help all users of
>log4j that also use components that log with commons-logging.
>
>It may also get more people and components to use commons-logging
>API instead of logger-specific APIs - and that may mean they'll be able to
>choose the logger impl based on quality.

The source of our argument seems to be that JAXP is the model to follow.
Although there are similarities between the selection of an XML parser and
a logging library, the problem with logging is far more complicated.
With an XML parser, you get a parser, parse the document and it is over.
The problem with logging is different because:

1) logging calls are made thousands of times so the indirection through
an equalizer API (like commons-logging) has a performance impact

2) logging requires a configuration step. Currently this crucial step is
ignored in commons-logging.

3) In container based environments, it is important for the user to control
logging by carefully placing the log4j.jar file and its configuration file. By
introducing an extra indirection step (commons-logging detection mechanism)
this is  made hopelessly complex.

4) In future versions of Application Servers, it will be the job of the 
application
server to *impose* the (log4j) hierarchy and the specific Logger 
implementation.
This simply can not be achieved with commons-logging.

The point is that logging in some respects is more complex than XML parsing.

By the way, I am just curious, how many vendors (outside xml.apache.org)
implement JAXP? This has no direct bearing to the discussion.

Regards, Ceki





--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Comments on the commons-logging API

[Ceki Gülcü]

At 00:57 29.03.2002 +0100, Paulo Gaspar wrote:
>Ceki,
>
>What about making clear that commons-logging is only supposed to be
>used by other components so that the application developer picks
>the logging API that suits him best?

That seems to be the intent of commons-logging. I have pointed out
the problems with that approach.

>Do you really believe that all application developers will use
>Log4J? Or do you want to force them into doing that?

I can't force people to do anything.

>Do you have any doubt that lots of companies will follow the policy
>of using the JDK 1.4 Logging API just "because it is the one that
>comes with Java"?

Yes, I have my doubts. It still takes a human brain to program a
computer. This is not different in Java. This fact is to remain valid for the
foreseeable future.

>Do you really think that the persons imposing such decision will
>care about what is good and what is bad?

Yes. People have brains.

>And then the ones getting the mess will be the developers and the
>commons-logging will help those. And will also help them to use
>the components/libs that use it.

Possibly.

>This sounds like just another of your pro-log4j-anti-anything-else
>campaigns, containing the usual amount of FUD of any blind campaign.

Please avoid making generalizations.

>A "blind campaign" is one where the single motivation of the
>campaigner is defending some interest/belief against all others...
>without really trying to SEE or get precise information on what
>those others really are.

I have a right to speak my mind as much as you do.

>The blindness towards the other alternatives tends to grow a
>considerable amount of misinformation on the blind campaigner and,
>then, he vigorously spreads it - hence the resulting spread of FUD.
>
>You seem to be following a pattern here, since you are doing just
>the same as you usually do against LogKit, including the
>misinformation bit.
>
>Although both you and Peter turn a bit silly when under the
>influence of another-logger-war, I always notice that you know much
>less about LogKit than Peter knows about log4j. (And yes, I know
>both well enough to clearly notice that).

The issue with LogKit is entirely different. The current debate is
perhaps tense  but well within the bounds of mutual respect and
civility. I made my reservations about the commons-logging API
and its developers presented their counter arguments.

>It is sad that you show to be more interested on destroying the
>"competition" than on learning from it. Well, at least you did not
>accuse the commons-logging guys from plagiarism just yet, as you
>did about the LogKit guys.

I never suspected (nor suggested) that commons-logging effort was
dishonorable in any way. My contention is that it will make life harder
not easier. Nothing more, nothing less.

 > -Original Message-
> > From: Ceki Gulcu [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, March 28, 2002 11:14 PM
> > To: Jakarta General List
> > Subject: Re: Comments on the commons-logging API
> >
> >
> > At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:
> >
> > >I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
> > >something better came along).  Generally, commons-logging
> > neither encourages
> > >nor discourages use of Log4J.  However, I would argue that it _does_
> > >encourage Log4J a bit by not forcing a logging implementation war.
> >
> > True. It does encourage it, but only initially. On the long run,
> > however, people will run into problems with their logging (as is
> > happening now). They will say this commons-logging+log4j stuff is too
> > complicated, we'll switch to JDK 1.4 logging, at least that does not
> > have any CLASSPATH problems.
> >
> > >The fact is, JDK 1.4 logging in particular is going to become
> > more and more
> > >common over time, and unless someone can summon forth a magic
> > recantation of
> > >that JSR, then a component-level interface with popular loggers is
> > >necessary.  Otherwise you have to pick, which only services us at the
> > >expense of those who use other logger implementations.
> >
> > Possible but I would not be that sure.  We will have very strong new
> > features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
> > logging even further behind.  Just as importantly, log4j documentation
> > is going to get a massive boost with the upcoming log4j book.
> >
> > Sun's me-too strategy is bound to fail. The question is whether the
> > bigger jakarta community is going to help us defeat JSR47 or stand in
> > the way.
> >
> > --
> > Ceki
> > My link of the month: http://java.sun.com/aboutJava/standardization/
> >
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

Costin,

I think you have done a pretty good job on the log4j wrapper. However,
I am pretty stretched out as it is, so I can't really help with something
I don't particularly like. Besides, if people find commons-logging really 
useful
they will build a community around it. What I say or think won't matter.

At 15:17 28.03.2002 -0800, you wrote:
>On Thu, 28 Mar 2002, Ceki Gülcü wrote:
>
> > True. It does encourage it, but only initially. On the long run,
> > however, people will run into problems with their logging (as is
> > happening now). They will say this commons-logging+log4j stuff is too
> > complicated, we'll switch to JDK 1.4 logging, at least that does not
>
>And you are the only one who can make commons-logging + log4j to be
>the best solution on the long run.
>
>By implementing and maintaining the log4j implementation of
>commons-logging.
>
>The API is a subset of log4j, and if you really want to help the users
>all you have to do is take ownership of a log4j implementation of
>commons-logging.
>
>It doesn't even have to be included in commons-logging, it is
>better if each log4j impl. had it's own implementation of the wrapper,
>possibly taking advantage of new features, etc.
>
>Costin

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 16:33 28.03.2002 -0600, you wrote:
> > Sun's me-too strategy is bound to fail. The question is whether the
> > bigger jakarta community is going to help us defeat JSR47 or stand in
> > the way.
>
>That's a bit harsh, isn't it?

Hmm, maybe it is. What I am trying to say is that I would have liked
to see jakarta present a more united front. Well, too bad...

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 15:30 28.03.2002 -0600, Morgan Delagrange wrote:

>I am pro-Log4J.  I wish I lived in that Log4J-only world (until/unless
>something better came along).  Generally, commons-logging neither encourages
>nor discourages use of Log4J.  However, I would argue that it _does_
>encourage Log4J a bit by not forcing a logging implementation war.

True. It does encourage it, but only initially. On the long run,
however, people will run into problems with their logging (as is
happening now). They will say this commons-logging+log4j stuff is too
complicated, we'll switch to JDK 1.4 logging, at least that does not
have any CLASSPATH problems.

>The fact is, JDK 1.4 logging in particular is going to become more and more
>common over time, and unless someone can summon forth a magic recantation of
>that JSR, then a component-level interface with popular loggers is
>necessary.  Otherwise you have to pick, which only services us at the
>expense of those who use other logger implementations.

Possible but I would not be that sure.  We will have very strong new
features in log4j 1.3 (the release after 1.2) which will leave JDK 1.4
logging even further behind.  Just as importantly, log4j documentation
is going to get a massive boost with the upcoming log4j book.

Sun's me-too strategy is bound to fail. The question is whether the
bigger jakarta community is going to help us defeat JSR47 or stand in
the way.

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 15:10 28.03.2002 -0600, Morgan Delagrange wrote:
>Where is this world where "everyone" uses Log4J?

That world = (world - jakarta)


--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

Costin, Morgan, Rodney,

Thanks for the lively discussion and sharing your points of view. My intent
was to warn users of the dangers of using common-logging. I have done
my bit. Cheers, Ceki

At 16:31 27.03.2002 -0600, Morgan wrote:
>I believe the order of precedence is well documented.  I think the logging
>component would benefit from warning messages when a default implementation
>is selected (like Log4J warns you when there is no log4j.properties file
>available), but this doesn't require any fundamental change to the API.
>
>If you want to take about confusion and despair, look at the environment
>that's running three logging implementations simultaneously.
>
>- Morgan

--
Ceki
My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Comments on the commons-logging API

[Ceki Gülcü]

At 15:18 27.03.2002 -0600, Morgan Delagrange wrote:
>Here's the problem, as I see it.
>
>Suppose Commons component A decides to adopt Log4J, Commons component B
>decides to adopt LogKit, and Commons component C adopts JDK1.4 logging.
>They will all minimally function with the right jars in the classpath.
>However you (the end-user) are left with maintaining configuration for 3
>different logging APIs, which is tedious at best.  When you take into
>account cool features like variable log levels, Log4J appenders and the
>like, you're pretty much guaranteed to swallow up useful configuration
>options because sophisticated configurations are too difficult to maintain
>over mutiple logging implementations.
>
>Contrarily, if all three Commons components use a logging facade, you can
>focus all your configuration efforts on one logging implementation.  Sure,
>there is a trade-off; you don't have access to all the features, and the
>interface between the facade and the implementation must be maintained.  But
>the benefits are not just political; they potentially make the end-users
>configuration much easier.

So, if I understand correctly the reason for adopting commons-logging
API is for convenience rather than non-intrusiveness as a library
(with respect to logging).

With commons-logging, the end user will only have to configure the
logging API that common-logging selects (or detects) but the selection
mechanism is dynamic such that there are many ways and reasons for
which the selected API will be the wrong one. This is the uncertainty
factor I am talking about.  Uncertainty breeds confusion and confusion
breeds despair.


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

RE: Comments on the commons-logging API

[Ceki Gülcü]

At 11:49 27.03.2002 -0600,  Rodney Waldhoff wrote:

>But this isn't really the reason commons-logging was created.  Note that
>most of the commons components are just that--tiny libraries meant to be
>integrated/incorporated into larger frameworks and larger applications.
>Some of these components need/want logging capabilities, or at least some
>people need/want some components to have logging capabilities.  But it seems
>a obtrusive for some tiny library to dictate the logging framework (if any)
>that should be used by the larger application that contains it.  So the
>component is stuck with a decision between not using logging at all, or
>forcing some "standard" logging implementation upon the larger framework,
>and the containing application is stuck with either converting everything to
>this "standard" logging implementation (and hoping that each component
>agrees on what that is) or having a heterogeneous set of logs and logging
>implementations.  Search-and-replace code switching isn't really an option
>for the commons components, or at least not a terribly good one.

If your library chooses to use logging API XYZ, this does not impose
XYZ to the clients of your library. Your clients can use the logging
library they prefer (if they are using logging API) and your library
can use XYZ. One choice does not necessarily influence the other. For
example, the fact that JBoss uses log4j does not impose a logging
library to the bean developer. Similarly, Tomcat's logging library
does not prevent web-app developers from using log4j.

In other words, the argument about (jakarta-commons) components
dictating a logging API to the containing application is widely
accepted although very dubious in my opinion.

Anyway, I think we have been through all this already. I do not expect
to be able to convince anyone altough I suspect uncertainty and the
bug reports will, slowly but surely.

>Commons-Logging is meant to provide an alternative solution: create a
>facade/adapter around an arbitrary logging API, use it at the common
>component level, and allow the user (the containing application) to select
>which specific logging implementation (if any) to use.  Then the same binary
>works everywhere, and in many (most?) cases, the commons-logging will just
>quietly do what you hope it would. (If you've got log4j, it uses it. If
>you've got JDK 1.4, it uses that. If all else fails, it doesn't do
>anything.)

I don't think "hoping quitely" and computers get along very well.

>An arbitrary application or system shouldn't feel compelled nor even
>(necessarily) encouraged to use commons-logging. That's not what it's there
>for.  It's there to allow the library components to delegate that decision
>to the containing application.

I understand your argument. I have already exposed mine. Thanks for your
attention. Ceki



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

Comments on the commons-logging API

[Ceki Gülcü]

Hello all,

Given that log4j is such a low-level library, most organizations are
suspicious to tie their code to log4j, especially considering the new
logging API in JDK 1.4.

Before going forward, it is appropriate to mention that these two APIs
are very similar.  The classical usage pattern for log4j is:

---

import org.apache.log4j.Logger;

public class MyClass {
   final static Logger logger = Logger.getLogger("some.name");

public void foo1() {
  logger.debug("Hello world.");
}

public void foo2() {
  logger.info("Another message.");
  logger.error("Stop that!", new Exception("The earth is getting 
warmer."));
}
}
---

As you are well aware by now, one of the important benefits of log4j
is that it can be configured at run time using configuration scripts.
You can have hundreds or thousands of log statement but only one or
two lines of code to configure log4j.

The usage pattern for the JDK 1.4 logging API is:

---
import java.util.logging.Logger;

public class MyClass {
final static Logger logger = Logger.getLogger("test");

public void foo1() {
  logger.debug("Hello world.");
}

public void foo2() {
  logger.info("Another message.");
  logger.error("Stop that!", new Exception("The earth is getting 
warmer."));
}
}
---

Do you notice anything similar? The JDK 1.4 logging API also admits
configuration scripts. Being part of the JDK, the common guess that
this API will supplant log4j some time in the future.

It is not so easy to write a complete logging API. Users
come to realize they need the features present in log4j but absent in
JDK 1.4 logging API.  Moreover, log4j runs with JDK 1.1 or later whereas
the JDK 1.4 logging API, requires, well, JDK 1.4.  Most users can't
afford to tie their code to JDK 1.4.

But they need logging and they need it now. A common strategy for
protecting against future changes and at the same time to benefit from
existing log4j features is to *wrap* log4j with a custom logging
API. Log4j actually has support to facilitate such wrappers.

It turns out that such wrappers are not that trivial to write. I frequently
receive email where a user runs into a problem with their wrapper and
requests help. More often than not, these wrappers are of poor quality
such that the cost of inactive (or disabled) logging statements is
multiplied by a factor of 1'000.

Of course, not all wrappers are of poor quality. For example, the
commons-logging API is rather well implemented. Obviously, there is
still a cost for the wrapping but it won't be of a huge factor.

The commons-logging API will try to use the JDK 1.4 API if present, or
the log4j API. The *current* preference is log4j I believe. Neat!

Now, it just happens that the part where most users have difficulty is the
initialization of the log4j API. Where should the log4j.jar go? Where
do I put the log4j.properties files?  Can I have different
web-applications have different log4j configurations?  How do I
initialize log4j in an application server?  Although there is ample
literature on the subject, much confusion remains.

The commons-logging API as it wraps multiple logging APIs such
as Avalon's LogKit, log4j, JDK 1.4 has its own "discovery process".
Things were confusing before, they will be even more when
commons-logging API enters "common" usage. With some effort, it might
start making sense to you. However, your users will not show the same
perseverance nor enthusiasm.

There will be also unexpected interactions between log4j and the
commons-logging API. For example, log4j 1.2alpha1 through alpha4 had a
very subtle bug which caused client code compiled with log4j version
1.1.3 to throw exceptions when ran with log4j 1.2alpha. Inversely,
code compiled with 1.2alpha would crash when ran using log4j 1.1.3.
This problem was fixed in log4j beta.

It is now sufficient for client code to be compiled with 1.1.x and to
run with 1.2 beta without problems and vice versa. Of course if
commons-logging compiled with log4j 1.2alpha the problem would be
sticky. It would not go away by compiling client code but only by replacing
the commons-logging API.

In the recent weeks I have also started to receive disturbing bug reports
where components using commons-logging API behave strangely.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7484
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6764

I suspect that these problems will only worsen in the future. The
commons-logging developers will suspect a log4j bug and we will
suspect a commons-logging API bug. By increasing the number of
components required for logging you have doubled the probability of
bugs while the difficulty of resolving them has increased by a higher
multiple.

Remember that the 

Re: Why Sun won't certify JBoss (was Re: "Jakarta is not an open source project in the pure community sense anymore")

[Ceki Gülcü]

At 09:50 23.03.2002 -0500, you wrote:
>On 3/22/02 12:19 PM, "James Strachan" <[EMAIL PROTECTED]> wrote:
>
> > A thought struck me today which is probably totally obvious to folk but I
> > thought I'd share it anyways. Sun gets pots of cash from companies who
> > develop J2EE compliant software from the J2EE license fees. So its in Sun's
> > interest to protect the BEA's, IBM's and their own J2EE products. The money
> > they get is based on revenue of the company (so thats quite a lot of money
> > from BEA & IBM).
> >
> > The money-men at Sun probably see open source J2EE solutions as lost 
> revenue
> > to possible commercial J2EE solutions so when folks like JBoss come along
> > they see it as in Sun's interest to not certify them to protect their J2EE
> > licence revenue nest egg.
> >
> > Though with the .NET competition now I think its in their interest to
> > protect their J2EE market place by allowing open source solutions; 
> otherwise
> > long term folks will just move away from J2EE.
>
>I think that it gets even worse for us - it's my understanding that since
>the J2EE licensees had to pay pots for the license,  bring open-source-able
>JSR's into that umbrella will dilute the value of the licenses they own.
>Therefore, it's conceivable that would be a motivation to oppose the opening
>of the J2EE API's.

This well may be case. It is pure speculation nonetheless. Or do you
know something I don't?

First, we don't know how much money Sun gets from licensing.

Second, the price of the license will drop if independent
implementations are allowed.  For App Servers, I think the barrier of
entry is in the difficulty implementating the spec not in the licensing.
It's going to be JBoss, Weblogic, and Webspere for a long time. As
such, BEA and IBM will be thrilled to see a lower price -- assuming the
price was high.

Again, my claims are long on speculation and short on facts.


--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: Now what? (was: Jakarta Overview)

[Ceki Gülcü]

At 14:47 22.03.2002 -0800, you wrote:

>- Audience and "Marketing":
>The document is directed towards people who may not be familiar
>with all the projects that exist under the Jakarta umbrella.
>Specifically, it is directed towards users, who hope to find
>something useful for their own projects. (Those users may turn
>into contributors over time!)
>I cannot understand why Leo and Ceki refer to the document (and,
>by implication, others like it) as "Marketing" - a term which
>carries in this context clearly condescending connotations.
>I don't think documentation is marketing - and what I tried to
>provide is simply documentation, not different in principle
>than Javadoc, only at a higher level.

I realize that you spent considerable amount of time editing
the document. I appreciate the effort. I assure you that there is
no condescension on my part, at least not intentional.

The introduction in your email came through as "here is the
solution to all Jakarta's problems." I have a hard time accepting
that as being the truth.

>It is also simply not true, as Ceki believes, that "everybody
>knows Jakarta": from the inside it may be hard to conceive how
>large and confusing the entire Jakarta project can appear to
>the outsider.

The Jakarta brand is very well known. What is less known are the
individual Jakarta subprojects, in particular their relation with each
other.  I doubt the overview document will solve that conundrum.

As I said in my previous comments, I do not have a problem with the
contents of the document per se but the sprit in which it was
presented. IMO, it would have been preferable to work with each
individual subproject rather than start a new body of work but that was
not my decision to make.

Are you willing to continue maintaining it? Make sure that it is
comprehensive, consistent and up to date? What will happen when you
grow tired of it?

Nothing is preventing you from continuing to work on the
overview.  If you persist, my -1 will be withdrawn or overridden. What
is certain is that the overview is yet another brick on of the edifice
of Jakarta.


>Philipp K. Janert, Ph.D.  [EMAIL PROTECTED]

--
Ceki

My link of the month: http://java.sun.com/aboutJava/standardization/


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

Re: [OT] JCP rant

[Ceki Gülcü]

All very good points. The question on my mind is whether these
problems can be corrected in the future by opening up the (JCP) Java
Community Process or whether the closed-like-a-clamp is a symptom
of a more serious and profound disease - my suggested name would
be "clampitis."

Does anyone has a satisfactory answer? For one, Sun has been
uttering (muttering?) the correct noises lately. However, it is hard
to say whether they are sincere or just pre-JavaOne acting.

As you say, the issues are not related solely to licensing. When I
stop and ask: "what is in it for Sun?" the answers are not very
encouraging.

At 14:12 21.03.2002 -0500, you wrote:

>Somebody asked on the axi-user mailing list why they should use Axis
>instead of JAXM.  I offered some comments, but tried not to stray
>too off topic.  In light of a recent JCP-related thread, I thought
>there might not be any objections on general@jakarta if I vented for
>a minute.
>
>When you use JAXM, you'll run up against all sorts of limitations and
>the best you can do is send a suggestion/comment to an email address.
>With Axis, or any Apache project, if you run up against a limitation,
>you can discuss it on a mailing list and submit a patch.
>Hypothesis: JCP JSRs that have more frequent feedback iteration cycles and
>provide source code tend to produce better results than those with fewer
>feedback cycles.  I'll use JAXM and JAX-RPC as examples.  JAXM
>had no mailing list for developer discussion/feedback as it was being
>designed/developed with only the usual JCP JSR comment address.  JAX-RPC
>has a jaxrpc-interest mailing list that has helped the spec evolve into
>something more likely to be useful to developers.  With something as
>simple as a mailing list a JCP JSR can gather much better requirements.
>However, neither JSR provided source for their reference implementations,
>making debugging and patch submission an impossibility.
>
>The problem with the JCP is not merely the licensing.  It is also the
>basic JSR procedures.  The objective of a new API is to meet some set
>of developer requirements in a particular application domain.  If you
>don't consult with your users, the target developer group, you probably
>won't develop a useful result.  JSRs would produce better results if run a
>little more like Apache projects, with more opportunity for user feedback
>in an open forum to mold the ultimate result into something useful.
>
>daniel
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

--
Ceki


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

Re: Jakarta Overview

[Ceki Gülcü]

Isn't the "overview" document trying to substitute itself for the 
documentation that
is already in subprojects (or should be)?  The cornerstone of the Jakarta and
Apache Software Foundation in general is that "management"  delegates
responsibility for a given subproject to each subproject, intervening
as little as possible.

Your introduction also raises further worries. Jakarta does not need
more publicity. Everybody knows Jakarta. What is needed is improving
the quality of each *subproject*. Marketing gimmicks are not helpful and just
waste precious time.

More importantly, who is to decide what project has what maturity? I find
the "overview" document a little too interventionist, perhaps less in content
than in sprit. Until these concerns are addressed, here is my -1.

At 16:36 18.03.2002 -0800, you wrote:

>Greetings!
>
>I have been following some of the recent discussions on this
>mailing list about possible directions for the Jakarta project.
>
>I would like to offer the following observation: To have code and
>projects coming out of Jakarta being more widely adopted,
>developers first need to be aware of them, then they have to be
>able to judge whether a Jakarta project is suitable for the
>developers' needs.
>
>I believe that the Jakarta website could do more to make its
>products easily accessible. It is often not easy to tell what a
>project is actually about, what the project's scope is, how
>its functionality is achieved, or how mature and usable the
>existing code base is.
>
>Evaluating an of-the-shelf component usually is an iterative
>process: In a first step one tries to determine the overall
>purpose of the component, and whether it is suitable for one's
>purpose at all. In later steps, one may consider how the component
>works, and what distinguishes it from comparable/competing
>products.
>
>The Jakarta subprojects support this evaluation and decision
>process to various degrees. The one that I am most familiar with
>(Velocity) is exceptional in this regard (mere coincidence?). But
>some (sub-)projects force the potential user to study the Javadoc
>to find out which problem the project attempts to solve, which is
>probably unacceptable for many visitors.
>
>I think it would be helpful for everyone (in particular in light
>of the desire to see Jakarta code being more widely adopted in
>outside projects) to try to improve the information offered here,
>and to support visitors in their evaluation and decision process
>as much as possible.
>
>After this introduction...
>
>Here is what I have done: I have scoured the entire Jakarta
>website and compiled information not only on each project, but
>also on each of the subprojects (such as those in the Commons,
>or those that are part of Avalon or Turbine), which are not
>immediately visible when visiting the Jakarta homepage.
>
>For each project, I have included a short, one-paragraph
>description (often taken from the projects webpage), but I also
>tried to give a sense of the maturity and the activity of the
>project. For anybody wanting to use (as opposed to develop)
>Jakarta code in their own projects, this information will play a
>significant part in their final decision. (I report the version
>number as proxy for the maturity and the extend of the News
>section of each project as proxy for its activity.)
>
>I hope that by providing the information not only about the
>top level project, but also about all the individual subprojects
>in one location, a visitor to the site will have an easier
>time assessing purpose and scope of each of the projects.
>
>I would hope that this can be extended in the future to include
>the following:
>- a concise abstract, stating what the project is about and
>   what purpose it serves (the foundation for which I hope
>   to provide here, based on what many projects already offer on
>   their individual homepages)
>- a description how the project works, possibly by walking the
>   visitor through a "Hello, world" example application. (Some
>   Jakarta projects are exemplary in this, others are not. In
>   particular for the larger projects, such as Avalon, Turbine,
>   Struts, Jetspeed it is not easy to find out how to use them
>   in one's own work and what benefits would be derived. Very
>   extensive study is needed to find out whether the project
>   would even be applicable.)
>- a comparison with comparable projects (Velocity is exemplary
>   in that).
>
>I am not deeply familiar with many of the Jakarta projects (in
>particular, I can't quite fathom the full extend of some of the
>frameworks, such as Avalon or Turbine, at this time), but in the
>spirit of 'release-early/release-often' I would like to make the
>information I have compiled so far available to the community. Any
>feedback (if polite) is welcome, in particular corrections from
>people more knowledgeable about a given project. I will try to
>incorporate anything useful and feed it back into the community.
>As time goes on, I will try to 

Re: cvs commit: jakarta-poi/build/jakarta-poi/docs/apidocs/org/apache/poi/util - New directory

[Ceki Gülcü]

At 09:07 07.03.2002 -0500, you wrote:
>Hi Stefano,
>
>I totally agree, here is the problem:
>
>I've offered to write this script provided with the relevant
>server/directory information.  I've offered to help however I can to get
>the POI website up, the builds and releases up, etc.
>
>No one has taken me up on it.  Via CVS is the ONLY way modifications can
>be made to our website.

Have you considered to just copy your files to the relevant directory on 
the web site?
CVS is *not* necessary to manage the web site.


--
Ceki


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

RE: [VOTE] ASL vs. GPL page: is this okay?

[Ceki Gülcü]

At 16:17 06.03.2002 -0600, you wrote:
>-1
>
>I'm not sure we need this at all.

I disagree. I think we definitely need a solid document countering the 
idyllic but false world depicted
by the FSF. It's just a gargantuan task to come up with a such a document. 
Regards, Ceki



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

Re: [VOTE] ASL vs. GPL page: is this okay?

[Ceki Gülcü]

ml
>A good general reference of open source licenses is Bruce Perens' book "Open
>Sources: Voices from the Open Source Revolution" at
>http://www.oreilly.com/catalog/opensources/book/perens.html

The "Working Without Copyleft" article is remarkably good. The point
about the FSF controlling the LGPL is another very significant point:

   The Free Software Foundation controls the license. They can release a
   new version of the license, which then will automatically apply to our
   software. Although we do not expect the Free Software Foundation of
   making changes that deviate from the spirit of the current versions,
   they could make clarifications that are contrary to our
   intentions. For example, they may clarify that the result of
   aspect-oriented weaving is subject to the terms of the LGPL, whereas
   we had intended that it is not. Another concern is who will be in
   charge of the Free Software Foundation 10 years from now, or what
   happens if the Free Software Foundation is discontinued? [LGPL,
   section 13]

Licensing is a blackhole for time. It also happens to be central element in
open source development. Its importance cannot be overstated.


--
Ceki Gülcü


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: ASL vs. GPL page?

[Ceki Gülcü]

Jeff,

Thanks for the link to this article. I found it to be well researched,
well written and instructive.  The "quodque pro quo" twist is rather
elegant, perhaps too elegant. From the comments on this list, I think that
most programmers tend to ignore licensing considerations. Does boring
lawyer mumbo-jumbo sound familiar?

Licensing issues are very confusing, at least in my mind. Putting aside our
reservations against the Free Software Foundation or the GPL, Richard
Stallman has authored make, gnu c compiler, and the beloved
emacs. This is more than most developers will achieve in 10 lifetimes,
yours humbly included. It is fascinating that he put so much energy in
to this copyleft vision and how far he carried it. My hat is off to RMS.

Regards, Ceki

At 22:16 05.03.2002 +1100, you wrote:
>Hi,
>
>Is there a page somewhere at apache.org, explaining why anyone would want to
>switch from GPL to ASL? The GNU.org site paints a very inspiring picture of a
>world of Free Software. It would be nice if there was an Apache equivalent
>somewhere explaining the Apache philosophy. This could be used as 
>ammunition by
>people trying to "convert" useful GPL'ed projects. I'm sure many Jakarta
>members have found themselves in this situation.
>
>Personal perspective: I know I was quite shocked when I first heard someone
>here say "GPL sucks" (back in fighting-with-webmacro days:). I didn't know how
>to take it. What kind of philistine wouldn't want RMS's vision of Free 
>Software
>to come true? It took me a long time (as a university student) to understand
>why the GPL truly does suck as a license for business use.
>
>So, a) is there anything out there already, and b) if not, anyone want to
>volunteer? :) I'm not very qualified, but could certainly provide 
>something for
>a "testimonial" section.
>
>Here's a starting resource:
>
>http://www.oreillynet.com/lpt/a//policy/2001/12/12/transition.html
>
>"   Working Without Copyleft
>
>   It's possible to be an ardent supporter of open source development
>   and not be a fan of copyleft and the General Public License. In this
>   article the authors -- software developers -- relate how they came to
>   embrace copyleft, became disillusioned with its limitations, and
>   consequently turned away from it.
>"
>
>--Jeff
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 


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

Re: cvs commit: jakarta-site/xdocs index.xml

[Ceki Gülcü]

-1

I disagree with this change because it gives the impression that
LogKit is a top level jakarta project which is not the case. The
addition is placed just to log4j giving the impression that the two
packages have equal footing. This misleads the users to think there
are two logging packages sanctioned by the Jakarta project.

I am undoing this change pending a decision by the PMC or any other
collective decision. Regards, Ceki

ps: I went away on vacation on the 23rd of February and came back just
today so I could not react earlier.

--
Here is Peter's original message from the 24th.

On 24 Feb 2002 08:38:13 - Peter Donald wrote:

donaldp 02/02/24 00:38:13

   Modified:docs index.html
xdocsindex.xml
   Log:
   Add LogKit blurb.

   Revision  ChangesPath
   1.62  +12 -0 jakarta-site/docs/index.html

   Index: index.html
   ===
   RCS file: /home/cvs/jakarta-site/docs/index.html,v
   retrieving revision 1.61
   retrieving revision 1.62
   diff -u -r1.61 -r1.62
   --- index.html   20 Feb 2002 03:52:05 -  1.61
   +++ index.html   24 Feb 2002 08:38:13 -  1.62
   @@ -308,6 +308,18 @@



   +LogKit:
   +
   +
   +
   +
   +A fast and well designed logging toolkit.
   +
   +
   +
   +
   +
   +
ORO:





   1.31  +4 -0  jakarta-site/xdocs/index.xml

   Index: index.xml
   ===
   RCS file: /home/cvs/jakarta-site/xdocs/index.xml,v
   retrieving revision 1.30
   retrieving revision 1.31
   diff -u -r1.30 -r1.31
   --- index.xml20 Feb 2002 03:52:08 -  1.30
   +++ index.xml24 Feb 2002 08:38:13 -  1.31
   @@ -106,6 +106,10 @@
A fast and flexible logging library for Java.


   +LogKit:
   +A fast and well designed logging toolkit.
   +
   +
ORO:
Set of text-processing Java classes that provide Perl5 
compatible regular expressions, AWK-like regular expressions, glob 
expressions, and utility classes for performing substitutions, splits, 
filtering filenames, etc.

   


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

version numbers in jars

[Ceki Gülcü]

The following is from http://www.ibiblio.org/java/#recent

I have a request to make of the log4j team, as well as all the other
Java programmers at the Apache Project, IBM alphaWorks, Sun, and
everyone else who distributes JAR archives. Could you please attach a
version number to all your JARs? I maintain several systems whose ext
directories I try to keep in sync. However, it's extremely difficult
to do this when there's no straight-forward way to look at log4j.jar
(or xercesImpl.jar, servlet.jar, jedit.jar, saxon.jar, or any of the
several dozen other jar archives I work with on a daily basis) and
quickly tell which version it holds. I personally experience this
problem mostly with XML related jars, but the problem is hardly unique
to XML. It's especially problematic when some other software requires
a particular version of a third-party jar. For instance, IBM
alphaWorks' XML Security Suite works with Xerces 2.0 beta 2 but not
earlier or later versions. The Apache XML Security project works with
the release version of Xalan 2.2 or later. My own XInclude software
works with Xerces 1.4.0 through 1.4.3 but not earlier or later
versions.

Mostly I just add numbers to the jar archives when I copy them into my
ext directory. However, that step is often forgotten, and it's almost
never been done when I'm working with somebody else's system
(e.g. trying to debug some student's homework for him or her). And
when a distribution like FOP bundles several third party jars like
Batik and the Bean Scripting Framework, they often don't bother to
tell you which version they've bundled. It would be much easier if all
JARs included appropriate version numbers in their names. It's also
important that JARs name themselves with their sources for JARs that
may come from multiple places. A good example of what to do is the
Bouncy Castle JCE implementation. It's called
"bc-jce-jdk13-112.jar". You can tell at a glance that it's version
1.1.2 of the Bouncy Castle implementation of the Java Cryptography
Extension for Java 1.3. Even if that isn't obvious, you most certainly
won't confuse this with any other implementation of the JCE (of which
there are several).


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

Re: Jakarta PMC Nomination - Rejection

[Ceki Gülcü]

Shit. You'll be sourly missed. I guess we could not expect you to be
the ugly duckling for ever. 

Best of luck with your new project. No doubt you'll do well.

At 12:19 01.02.2002 -0800, you wrote:
>Hey all,
>
>I just wanted to say that I'm not going to accept my Jakarta PMC nomination
>and do not want to be included in the voting for the next election.
>
>I have been involved with Java Apache/Jakarta since Sept 1996 and I think
>that it is time for me to move on from being politically responsible for
>this group. Honestly, I'm jaded and burned out on it all.
>
>That said, I recently signed a 10 year lease on a prime event space in
>downtown San Francisco and I am moving towards spending more time being a
>big time night club owner than working on Jakarta. More info:
><http://www.studioz.tv/> (p.s. that site is built with Anakia )
>
>I also just released Scarab 1.0b1 and am focused primarily on making Scarab
>the best issue tracking tool around. Expect to see more great developments
>on this project. It is by far, one of the best designed, largest and most
>complex pieces of software that I have ever had the pleasure of helping
>develop. It will be around for a very long time and will eventually put
>Bugzilla out of business. More info: <http://scarab.tigris.org/>
>
>thanks,
>
>-jon
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
Ceki Gülcü



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: PMC Nomination - Ceki Gulcu

[Ceki Gülcü]

Geir, Daniel, thanks for the nomination but I have to decline. Other
commitments are taking much of my time and I could not dedicate the
required attention to PMC related matters.  Besides, one does not have
to be a PMC member to contribute effectively to Jakarta.

By the way, I like to congratulate Dirk-Willem van Gulik, Jim
Jagielski, Ben Laurie and Sam Ruby for the organization of these
elections. Well done, very professional work. Drafting such precise
election rules (in our very distributed environment) is an achievement
in itself. With hindsight, it now seems so easy.

At 19:25 31.01.2002 -0800, you wrote:
>"Geir Magnusson Jr." <[EMAIL PROTECTED]> writes:
>
>> I nominate Ceki Gulcu to be a candidate for the PMC election.
>>
>> Ceki is the force of nature behind log4j, a member of the ASF, until
>> recently a member of the PMC, and one who I find is generally clear thinking
>> and fair when it comes to open source development and community issues.
>>
>> Of course, his debates with Peter are something else entirely... :)
>
>Ceki will make an excellent PMC member, +1.

--
Ceki Gülcü



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [Fwd: cvs commit: jakarta-site2/xdocs index.xml]

[Ceki Gülcü]

The Java Community Process (JCP) is not a "community" process at
all. It's a way for Sun Inc. to claim they are open. You know it. I
know it. Sun knows it. Let's stop deluding ourselves shall we?

I say we move "that flaming fireball" to the home page of *Apache*. 

-- 
Ceki

At 17:10 30.01.2002 -0500, Ted Husted wrote:
>I'm not comfortable with carrying this type of editorial matter at the
>top of the home page, and would like to move it to the news and status
>page. 
>
>-Ted.
>
> Original Message 
>Subject: cvs commit: jakarta-site2/xdocs index.xml
>Date: 30 Jan 2002 21:53:04 -
>From: [EMAIL PROTECTED]
>Reply-To: "Jakarta WebSite CVS List" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>
>jon 02/01/30 13:53:04
>
>  Modified:docs index.html
>   xdocsindex.xml
>  Log:
>  lets have a little fun.
>  
>  Revision  ChangesPath
>  1.52  +32 -0 jakarta-site2/docs/index.html
>  
>  Index: index.html
>  ===
>  RCS file: /home/cvs/jakarta-site2/docs/index.html,v
>  retrieving revision 1.51
>  retrieving revision 1.52
>  diff -u -r1.51 -r1.52
>  --- index.html29 Jan 2002 01:47:06 -  1.51
>  +++ index.html30 Jan 2002 21:53:03 -  1.52
>  @@ -140,6 +140,38 @@
>  
>
> 
>   
>  +  That
>flaming fireball in the sky...
>  +
>  +  
>  +  
>  +
>  +
>  +In a recent href="http://www.theserverside.com/resources/article.jsp?l=SunInterview";>article,
>Karen Tegan, Director of J2EE Compatibility and Platform
>  +Services for Sun Microsystems, had the following to say:
>  +
>  +
>  +"The J2EE Compatible brand has achieved significant momentum over the
>  +past two years, and we want to make sure that any open source efforts
>  +don't impact the viability of that effort."
>  +
>  +
>  +In other words, Sun doesn't give a hoot about whether J2EE licensing
>  +restricts open source J2EE products (in case you missed it, it does).
>  +Thus, the Apache Software Foundation's involvement in the Java
>Community
>  +Process (JCP) is simply an advertising statement for Sun to claim
>that
>  +they have a 'vision which uses open standards and non-proprietary
>  +interfaces'. If you would like to express your opinions of Sun's
>  +licensing terms, feel free to contact href="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED] and let us know what you
>  +think. Thanks.
>  +
>  +
>  +
>  +  
>  +  
>  +
>  +cellspacing="0" cellpadding="2" width="100%">
>  +  
>  +
> Welcome
>   
> 
>  
>  
>  
>  1.21  +28 -0 jakarta-site2/xdocs/index.xml
>  
>  Index: index.xml
>  ===
>  RCS file: /home/cvs/jakarta-site2/xdocs/index.xml,v
>  retrieving revision 1.20
>  retrieving revision 1.21
>  diff -u -r1.20 -r1.21
>  --- index.xml 20 Jan 2002 16:28:07 -  1.20
>  +++ index.xml 30 Jan 2002 21:53:03 -  1.21
>  @@ -9,6 +9,34 @@
>   
>   
>   
>  +
>  +
>  +In a recent  
>+href="http://www.theserverside.com/resources/article.jsp?l=SunInterview";
>  +>article, Karen Tegan, Director of J2EE Compatibility and
>Platform
>  +Services for Sun Microsystems, had the following to say:
>  +
>  +
>  +
>  +"The J2EE Compatible brand has achieved significant momentum over the
>  +past two years, and we want to make sure that any open source efforts
>  +don't impact the viability of that effort."
>  +
>  +
>  +
>  +In other words, Sun doesn't give a hoot about whether J2EE licensing
>  +restricts open source J2EE products (in case you missed it, it does).
>  +Thus, the Apache Software Foundation's involvement in the Java
>Community
>  +Process (JCP) is simply an advertising statement for Sun to claim
>that
>  +they have a 'vision which uses open standards and non-proprietary
>  +interfaces'. If you would like to express your opinions of Sun's
>  +licensing terms, feel free to contact   +href="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED] and let us know what
>you
>  +think. Thanks.
>  +
>  +
>  +
>  +
>   
>   
>   

Re: [PROPOSAL] POI @ Jakarta

[Ceki Gülcü]

At 14:45 17.01.2002 -0500, Andrew C. Oliver wrote:
>Proposal for "POI" - A Jakarta Subproject 
>version 1.0 - 17 Jan 2002 
>
>(0) rationale 
>
>The POI project seeks to provide pure Java APIs for reading, creating 
>and manipulating files written in formats based on Microsoft OLE 2 
>Compound Document Format.  The POI project has already successfully 
>created a Pure Java OLE 2 Compound Document Format library (POIFS) and a
>port of the Microsoft Excel '97(-2002) file format (aka XLS, BIFF8) and 
>tools for serializing XML in these formats (which will be hosted as part
>of Cocoon 2). 
>
>The POI project user community is growing leaps and bounds in usage as 
>evidenced by its position as one of the most active projects on 
>SourceForge and the 2,290 people who have downloaded it so far this 
>month.  The POI project currently has two active developers.  The 
>development community  might be small but is fanatically committed (and 
>growing rather  quickly).  It is likely that the upcoming port of the  
>Microsoft Word 97 File format will increase the size of the development 
>community, not to mention the user community.  The documentation is 
>comprehensive and includes full documentation on the previously 
>undocumented (or at least incompletely documented) Microsoft OLE 2 
>Compound Document Format. There are also HOW-TO documents that 
>illustrate use cases and examples. Lastly, The project founders have 
>agreed to collaborate with a developer at the OpenOffice.org project on 
>the Excel File Format Documentation. 
>
>Many Jakarta projects could potentially take advantage of POI and its 
>use in Jakarta will likely further seed the POI developer community. 
>POI is a unique project in the Java world.  Up until now there have been
>no successful free attempts to provide read/write access to OLE 2 CDF or
>MS Excel (97+) file formats. POI coupled with other Jakarta technologies
>could produce some highly useful offspring.  A few specific examples 
>might be Office Document indexing for Lucene, Velocity generating Excel 
>and Word document presentations, Office document management capabilities
>for Slide as well as content delivery and editing in Turbine. 

Hi Andrew,

Have you asked the Lucene people whether they were interested in using
POI? Is the slide community interested? 

In addition, I don't see how a templating engine like Velocity could
use POI, but again I am not an expert on the topic.


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [PROPOSAL] Jakarta PMC bylaws change

[Ceki Gülcü]

+1

At 14:27 16.01.2002 -0500, you wrote:
>The number of PMC seats will be set at seven.  Annually, all seven seats
>will be up for renewal.  The ASF board will be asked to provide a person or
>persons to administer the nominations and a subsequent ballot. The
>administrator(s) will determine the mechanics of the voting procedures.
>Any committer to any Jakarta code base will be eligible to vote.  Once the
>new PMC is in place, the first order of business will be to determine a
>chairperson from amongst their ranks.
>
>Once ratified, this proposal would be effective immediately, and an
>election would be initiated.
>
>- Sam Ruby




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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: License change for new year ?

[Ceki Gülcü]

I am not a lawyer and the following is yet another one of my heretical POVs.

Legally speaking the copyright notice is not even required in each source file as long 
as the whole work can be unequivocally attributed to their rightful owners through 
other means.

Example 1) In my home I don't have my name written on every item and piece of 
furniture. There is a littler sign on the door that says this is my home. It follows 
that everything contained therein is my property. 

Example 2) If you look inside any book, you are likely to find that there is only one 
copyright notice covering the whole book. You are very unlikely to find another 
copyright in no sentence, no paragraph, nor in any section not even in any chapter. 
You will find one copyright section inside the cover page. 

Copyright law applies the same way to software as to books. 

Tearing out a page from a book does not remove the copyright of the author even if 
there is no copyright notice on the torn out page. Think about it for a second.

Why are putting copyright notices in every source code file? Because we can and it is 
admitted by industry practice, not because we have to. 


At 22:29 09.01.2002 -0500, Ted Husted wrote:
>At this time, the so-called short form should not be used. Although we
>are told that it is legally defensible. 
>
>http://nagoya.apache.org:8080/jyve-faq/Turbine/screen/DisplayQuestionAnswer/action/SetAll/project_id/2/faq_id/38/topic_id/205/question_id/787
>
>The ASF chair has made a posting to the Committers list regarding a new
>license, which will support a short form, but approval is still
>forthcoming. 
>
>-Ted.
>
>
>"Andrew C. Oliver" wrote:
>> 
>> Pete,
>> 
>> Just a question.  Maybe I missed this in the discussions.  Every once
>> and a while the "short license" versus "big license" discussion goes
>> through here.  Meaning the source code for some projects whether
>> correctly or incorrectly be convention uses a statement and short
>> reference to the license and others post the license in its entirety.
>> Did anyone consult those "licensing" folks to check if there was a legal
>> reasoning?  While I have no particular passion on this and don't wish to
>> see a war here, I do know some projects use one and others use another
>> and I'm just curious if there are any legal problems that could result.
>> 
>> (at POI we use the long form convention because it seems to be in line
>> with where the discussion leaned on here and I'm a paranoid type person)
>> 
>> Thanks,
>> 
>> Andy
>> --
>> www.superlinksoftware.com
>> www.sourceforge.net/projects/poi - port of Excel format to java
>> http://developer.java.sun.com/developer/bugParade/bugs/4487555.html
>> - fix java generics!
>> 
>> The avalanche has already started. It is too late for the pebbles to
>> vote.
>> -Ambassador Kosh
>> 
>> --
>> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Building Java web applications with Struts.
>-- Tel +1 585 737-3463.
>-- Web http://www.husted.com/struts/
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: License change for new year ?

[Ceki Gülcü]

Geir,

I think the rule is so obvious once stated that no one is likely to disagree with it. 
In a perfect world, we would vote on such a rule in order to adopt it formally. 
However, we don't live in a perfect world with unlimited resources and the Jakarta 
tradition of lazy approval seems to apply. Regards, Ceki
 
At 20:24 09.01.2002 -0500, Geir Magnusson Jr. wrote:
>On 1/9/02 12:53 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
>
>> on 1/9/02 6:49 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>> 
>>> Ted Husted wrote:
>>>> 
>>>> I think on a continuing basis, Committers should update the copyright
>>>> notice to include the current year whenever they update a source file.
>>>> This will happen most often in the early part of a year, but should
>>>> happen year-round. So, as Peter said, if you revise a source file from
>>>> 1999, you should change the copyright notice in the license to read
>>>> 1999, 2002. If the file was from 2001, we would change it to 2001-2002.
>>> 
>>> I have never bothered to learn the details (there are some topics I avoid
>>> lest I become perceived as an expert on the subject ;-)), but when working
>>> on software for my employer (who has a tendency of being careful about such
>>> things), we tend to follow the roughly the rules specified above.
>> 
>> Hey Ted, can you update source.xml (or whatever appropriate jakarta-site2
>> file) in order to get that little rule 'documented'?
>> 
>
>Here's a quick question - what makes that a rule?  Ted putting it into a
>file?
>
>I don't disagree with the  suggestion - I mean, we need to do it - I am just
>asking what makes it a rule now
>
>
>On the issue itself, isn't this something that should be uniformly done
>across all Apache projects?
>
>I would think that since it's part of the License, we want uniformity.
>
>-- 
>Geir Magnusson Jr.   [EMAIL PROTECTED]
>System and Software Consulting
>You're going to end up getting pissed at your software
>anyway, so you might as well not pay for it. Try Open Source.
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Volunteer Wanted

[Ceki Gülcü]

First, the page is outdated, Java Apache is not Jakarta. Second, acting as a 
receptionist at desk with a million visitors a day is not what I call a dream job. The 
task should left to one person but shared on a rotational basis. 

I am willing to be the first and take over for *one* month. Any other volunteers? 
Regards, Ceki

At 14:57 08.01.2002 -0500, you wrote:
>I'd say it should be the [EMAIL PROTECTED] 
>
>and if anyone, including Paulo, want to help out with the Webmaster
>emails, that would be great.
>
>Jon Scott Stevens wrote:
>> 
>> I want to remove my name from this page:
>> 
>> <http://www.apache.org/foundation/preFAQ.html>
>> 
>> I nominate Paulo to put his name there instead so that he can start
>> contributing more than just being a pain in my ass. Is that cool?
>> 
>> -jon
>> 
>> --
>> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Building Java web applications with Struts.
>-- Tel +1 585 737-3463.
>-- Web http://www.husted.com/struts/
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Commons Validator Packaging/Content

[Ceki Gülcü]

The JBoss guys are very smart. Scott Stark is extremely high caliber. Mark is no idiot 
either. Jboss is successful because it is so fucking good. From where I stand, the 
other appservers are just copying JBoss. Where do you think the MBean architecture in 
Weblogic 6.x came from? 

The problem with JBoss is that while they innovate BEA and IBM make all the dough. 
Such is the nature of opensource. Bloody fucking hell!

(From what I hear Orion is pretty good too.)

At 02:18 08.01.2002 +0100, you wrote:
>> Jboss's success seems to be one project. I'm actually glad they went to
>> sourceforge...they would have struggled to survive here...
>
>How can you know?
>
>I have studied their code and their documentation some months ago, I 
>have also followed some of their mailling lists for sometime and that is
>not that obvious to me.
>
>I do NOT prefer what they call community. I do not find their code that 
>good. I do not like their documentation that much.
>
>JBoss success has a lot to do with the lack of credible alternative for
>something with a lot of demand, unlike Jakarta products like Tomcat or
>Velocity.
>
>Give me a better case and/or concrete reasons, please.
>
>
>Have fun,
>Paulo Gaspar
>
>> -Original Message-
>> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, January 08, 2002 1:25 AM
>> 
>> on 1/7/02 4:26 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
>> 
>> > Which projects are those?
>> > Can you really compare them - and their community - with Jakarta?
>> 
>> Jboss's success seems to be one project. I'm actually glad they went to
>> sourceforge...they would have struggled to survive here...
>> 
>> -jon
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: crushed

[Ceki Gülcü]

At 13:11 07.01.2002 -0800, Jon Scott Stevens wrote:
>on 1/7/02 12:44 PM, "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote:
>
>> I think many folks on
>> the list aren't listening to each other let alone to someone from the
>> outer circle.  
>
>That is my complaint about not just this list, but the entire project. We
>have people like Ted and Craig who are perfectly happy just sitting in their
>bubble sub-projects and doing whatever they want and you have people like
>myself who see a larger picture of what Jakarta is (or could be) and want to
>see people work together more and create less duplication of exactly the
>same functionality. Yes, that statement is based on their previous postings.
>
>> Its funny I kind of agree with some (but not all) of the points that Jon
>> guy makes but he seems to want to make them in such a way that they are
>> divisive instead of providing the leadership Stefano praises him for.
>> Leadership is taking the boat and sailing it and inviting others to come
>> along not sitting in the back complaining about the heading or
>> proclaiming "its just going to sink and the hell with you all maybe I'll
>> quit".  I hope he sees this and becomes the guy Stefano says he is.
>
>The problem is that I feel like the boat has already capsized, sank and
>rotted on the ocean floor. At this point, I'm pretty disheartened about
>Jakarta...more so than I have felt in over 6 years of being here. I have no
>other way to express my unhappiness than to express it by saying it. I feel
>like I can't change things anymore and about the only person who could is
>Sam, but I am not seeing him take the reigns in such a way to rebuild the
>ship...only to try to a lifeboat together over the next few years...
>
>If you look at how Scarab is run, we are pretty damn successful at this
>point with regards to building and managing a strong developer community
>around it. And it isn't even a Jakarta project. I personally see the model I
>have used for Scarab as pretty close to right way to run projects.
>
>Not that it is a contest, but I can guarantee I feel more crushed than you.

Have many developers does scarab have, 10? Jakarta has around 200 committers plus ten 
times that many developers. At 200'000 USD per committer that's a budget of 40'000'000 
USD a year. I'd estimate the budget of an equivalently sized software company at 
100'000'000 USD year. You think that's easy to manage? Sam's vision differs from yours 
and mine. That does not mean he is wrong and that you are right.  Anyway, what is 
exactly your vision? and how would you go about getting there? (How can you force 
people to cooperate more?)

How many places do you know where people keep arguing and arguing and still stick 
around? The only other place I know is my family. 

--

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Questions

[Ceki Gülcü]

Look, I think Sam is irreplaceable and so are you.  I don't want to even think about 
what would happen if anything happened to any of you. Heaven forbid. That's all I have 
to say on this. 

At 11:27 07.01.2002 -0800, Jon Stevens wrote:
>If Sam gets hit by a bus tomorrow, who would be willing to step up and take
>over the PMC chairmanship?
>
>
>p.s. I have no interest in being PMC Chair.
>
>-jon
>
>-- 
>Standard rules apply: Ask any questions, and you get the job. ;-)
>
>(I left this .sig in on purpose, because this quote is from Sam and I think
>it is funny based on the question.)

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Commons Validator Packaging/Content

[Ceki Gülcü]

At 10:33 07.01.2002 -0800, Jon Scott Stevens wrote:
>on 1/7/02 10:29 AM, "Jim Scott" <[EMAIL PROTECTED]> wrote:
>
>> IMHO, until the documentation is made part of the formal committing process,
>> the jakarta tools will only be valuable to the people who developed them.
>> 
>> I know that I am opening myself up to a serious flame, but that is the way I
>> see it.
>> 
>> Jim Scott
>
>No flame. That is a really good suggestion and one of the better $0.00 I
>have heard in a long time...
>
>The bigger issue would then to be to have Sam (the current PMC chair and
>person with the potential for authority) to take authority and mandate such
>an action over Jakarta.


Excellent topic. Much more neutral than code conventions. 

Who is going to judge the quality of documentation and enforce such a
rule if it is ever enunciated?

Let us instate a system based on referendum, where the shareholders
can directly intervene in making laws. By "shareholders", 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 shareholder vote. The result of the vote determines
whether the referendum is accepted or rejected. An accepted referendum
becomes law of Jakarta. 

This procedure is undeniably heavy. However, so is debating issues
without ever deciding. The advantage of a referendum is that once a decision is made 
you get peer pressure for free. Not PMC pressure, not chairman pressure but peer 
pressure!

Too heavy handed? OK, what is the alternative? 


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Commons Validator Packaging/Content

[Ceki Gülcü]

At 19:02 07.01.2002 +0100, you wrote:
>> Being PMC chair isn't going to help solve any problems because of
>> our system of checks and balances.
>
>I just love "checks and balances".
>It is the least perfect system except for all the others already tried.

Did you know that the delegates of the Constitutional Convention of 1787 were fearful 
of "popular rule" and hence the convoluted way for electing the US President? See 
Article 2, Section 1, Clauses 2 and 3 of the US Constitution. Amendment 12 changed the 
election system such that the people of a state voted directly for the electors 
instead of the state legislatures selecting the electors. The current system is still 
somewhat outdated as the recent Presidential elections have shown.

I am bringing this up because fear of popular rule is deeply ingrained in our psyches. 
This was so in 1787, still is in 2001. 

Anyway, I am not suggesting we create a system of checks and balances with judges, 
legislature and an executive. Jakarta is too small for that. Jakarta is much more like 
a software company then a nation. It should be run as such. Jakarta committers can be 
viewed as the shareholders of Jakarta.

In Switzerland, the ultimate decisional power of a corporation is vested in the 
general assembly, that is the assembly of shareholders. The same holds true in the 
rest of Europe and most probably in the US and the rest of the world as well.

We are all volunteers. Thus, it is impossible to dictate to Apache developers. 
However, they can be convinced, cajoled or gently pressured. Peer pressure is 
extremely effective but requires consensus. Consensus about the community's will, not 
your or my will, but the larger group's will, can be achieved as a result of a vote. 

In short: We vote. We get a decision about what we want. We implement what we want.  

Does it make sense? Regards, Ceki


>Have fun,
>Paulo Gaspar
>
>
>> -Original Message-
>> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, January 07, 2002 6:04 PM
>>
>>
>> on 1/7/02 8:55 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>>
>> >  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
>>
>> Being PMC chair isn't going to help solve any problems because of
>> our system
>> of checks and balances.
>>
>> In other words, I don't see PMC chair being any more important or
>> special or
>> enabled than simply being a member of the PMC, which I already am.
>>
>> As I already said, I also don't think I have enough backing to:
>>
>> #1. Get voted into being the PMC chair.
>> #2. Make enough of a change to help turn Jakarta around from a slow
>> spiraling death.
>>
>> -jon
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: Commons Validator Packaging/Content

[Ceki Gülcü]

At 19:00 07.01.2002 +0100, Paulo Gaspar wrote:
>> Jon wrote:
>>
>> There is no community. There is projects which have people who follow them
>> blindly.
>
>I do not believe that.
>
>What I am seeing are the same signs Sam sees:
>
>> Sam wrote:
>>
>> In my, admittedly biased, perspective, I see significant improvement in
>> terms of community over the course of the past eleven months or so.  For
>> starters, the following results would have been inconceivable at the time:
>>
>>http://jakarta.apache.org/builds/gump/2002-01-07/
>>
>> I also see an initiative by Ted and others to build a commons are which
>> promotes reuse.  Conscientious objectors notwithstanding, they plow
>> relentlessly ahead, continuing to make incremental and enduring progress.

Projects building cleanly is very nice and gump is great. However, I would not declare 
victory just yet. (Very few people can resists Sam's polite nudges.) Jon's concerns 
about the existence of a community are valid and should not be lightly dismissed. 

With the pending/rumored commercialization of SourceForge there will be even larger 
hordes of projects wanting to be hosted under Jakarta.  What will we do then? Regards, 
Ceki


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

Re: Commons Validator Packaging/Content

[Ceki Gülcü]

Jon,

I share precisely the same concerns. Thank you for standing up on this issue. 
What do you suggest we do? I mean concretely. 

My first suggestion would be to stop creating new projects, starting *today*. 
If someone wants to contribute code, they do that within the framework of an 
*existing* 
project. If that is not possible, then they do it somewhere else. Regards, Ceki

At 14:15 06.01.2002 -0800, Jon Scott Stevens wrote:
>on 1/6/02 1:45 PM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:
>
>> Jon, I presume that you are talking about the subject, and not the text you
>> are quoting.  In any case, a framework independent validator seems to me to
>> be valuable a reusable component.  If one or both can't be restructed to be
>> framework independent, then that would seem to be a reasonable explanation
>> for the duplication.  If both can, then merging of the best of both here in
>> commons would seem to be the wisest path.
>
>I don't see why the basis isn't Intake. Why not work to move Intake to
>commons and then work towards a framework independent implementation in
>Commons?
>
>Of course it is easier to start from scratch to invent yet another
>validation framework. This is where I see another failure of Jakarta. People
>only go with the easiest route without any concern about the long term mess
>they are making.
>
>I feel like Jakarta is just going down this path of having a bazillion
>different implementations and versions of the same thing and it is only
>getting worse. Commons was supposed to help clean that up by providing a
>central location, however all I see is it making it worse because people are
>just re-inventing what already exists in other projects instead of using
>existing projects as the basis.
>
>A perfect example of this recently was the discussion about Torque. Hey,
>Torque exists, but it is *easier* to re-invent it rather than simply spend
>the time to figure it out, understand it and move it to commons (or a top
>level project).
>
>I'm starting to realize that Jakarta has grown to becoming a place where
>people only scratch their own itches and I agree that that is the basis for
>open source. However, we have no overall direction. We all have our own
>opinions and spend days and days discussing them and when it comes down to
>putting code into CVS, people do whatever they want anyway because there is
>no set of checks and balances to put some sort of higher level control over
>things.
>
>In Java Apache, these issues never came up because there were only a few
>projects and a few people expressing their opinions. Now, Jakarta has grown
>into literally hundreds of people expressing their opinions and doing what
>they want. Commons has become an area where people have a free CVS commit
>tree to put whatever they want into it, which is fine, however these people
>doing the commits haven't spent the time to do things as simple as figuring
>out what the proper way to format code according to the Jakarta rules.
>
>People keep saying that Jakarta isn't broken. Well, if it isn't broken, then
>how come we have so many people doing their own thing and not working
>together? Jakarta is supposed to be a group collective, however it is
>becoming nothing more than another Sourceforge.
>
>-jon
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Cultural homogeneity

[Ceki Gülcü]

At 13:26 06.01.2002 -0500, you wrote:
>Peter Donald wrote:
>>
>>> Again, you might think the above is flip, but you are talking about
>>> modifying the charter here...
>>
>> The charter was modified ages ago. Sure the words haven't changed but it has
>> been a long time since jakarta project was actually true to the words in its
>> charter ... see Ant the "server-side" project
>>
>> So instead of accepting that we violate scope with more than half the jakarta
>> projects people took to inventing reasons to keep them at jakarta. ie Ant
>> became acceptable because it was a tool that could be used to build
>> serverside projects. How silly is that reason?
>
>Slightly revisionist.  Ant was part of the original charter for Jakarta.
>There was a sister project named "Java" which contained a number of other
>projects
>
>Just to have a little fun (and this time, it is very intentional)... the
>project I consider most "out of scope" is dvsl.  There is nothing server
>specific about it, and has everything in the world to do with XML.  Check
>it out for yourself: http://jakarta.apache.org/velocity/dvsl/index.html .
>
>I still maintain that scope is a distraction.  Community is what is
>important.

Agreed. Community is what is important. How is this consistent with your previous 
remarks about what Roy may think of widening the scope?  

More importantly, does the project (in the sense of XML or Jakarta) set the community? 
The projects influences the community but does not set it. There is emerging consensus 
that the umbrella projects we have are somewhat artificial. So what do we do? Shrug 
our shoulders and move on? Regards, Ceki


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Cultural homogeneity

[Ceki Gülcü]

At 03:35 07.01.2002 +1100, you wrote:
>On Mon, 7 Jan 2002 03:08, Ceki Gülcü wrote:
>> Some of the existing projects within Jakarta are server-side only, others
>> are client-side as well as server-side, none are client-side only. 
>
>except for JMeter ?

Well, JMeter is a client application to test the performance of a web server. It can't 
do anything else but test a server. So imho it's more "server-side" than many other 
projects we currently have. 

Server-side software in the case of Jakarta means software that is commonly executed 
by servers, most notably within servlet containers. This may include software that 
runs on the client but excludes software that runs *only* on client.

So, the word "server-side" might require some further clarification, but removing it 
completely is not just a cosmetic change. It means opening the flood-gates. 


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Cultural homogeneity

[Ceki Gülcü]

At 10:29 06.01.2002 -0500, you wrote:
>Ted Husted wrote:
>> (1) That we petition the ASF to change our charter and remove the word
>> "server", so what we are simply charged with providing production
>> quality solutions on the Java platform.
>> 
>> [I'd link to our charter, but can't find the ASF minutes any more, and
>> don't know where else it was published.]
>
>Found our copy at least -- 
>
>http://jakarta.apache.org/site/pmc/01-03-19-meeting-summary.html
>
>at 2.1
>
>So I'm thinking we might propose that our charter be amended to 
>
>RESOLVED, that the Jakarta Project Management Committee be and
>hereby is responsible for the creation and maintenance of
>-1  commercial-quality, open-source, server-side solutions for the Java
>+1  commercial-quality, open-source solutions for the Java
>Platform based on software licensed to the Foundation; and be it
>further

Some of the existing projects within Jakarta are server-side only, others are 
client-side as well as server-side, none are client-side only. Removing the 
"server-side" restriction would allow strictly client side applications such as word 
processors, editors, spread sheet programs, etc. into jakarta. 

Rewording of the charter is perhaps appropriate but completely removing the 
"server-side" restriction is not. I consequently vote -1 on the proposed change. 


>So that Ant, BCEL, and whatever would no longer be out of scope, and we
>could also consider client-side Java packages when they are proposed. 

Would you care to propose a different wording? 


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Ceki Gülcü]

At 18:02 05.01.2002 -0500, you wrote:
>Ceki Gülcü wrote:
>>
>> IMHO, XML does not and will never have a community as long as two of
>> its most important projects directly compete with each other. The
>> success of one is related with the failure of the other. XML
>> Community? Won't happen in a million years. How the did Crimson
>> become an Apache project anyway?
>
>Look closely, Xerces 2 is the designated successor to *both* Xerces 1 and
>Crimson.  The developers *are* working together.  I won't pretend that
>everything is 100% smooth sailing, but significant progress is being made.

Point well taken.

>> The required majority for the adoption of proposals can be simple or
>> qualified. Even if the qualified majority is 3/4, this would be better
>> than the veto system we have today. Although a veto can be overridden
>> by a 3/4 majority, as far as I know, this has never happened in the
>> past.  Today someone voting -1 means end of discussion.
>>
>> I dare anyone to -1 that. Regards, Ceki
>
>The rules you describe don't look familiar to me.  The ones I am familiar
>with are:
>
>http://jakarta.apache.org/site/decisions.html
>http://jakarta.apache.org/site/management.html

My mistake. I was always under the impression that new project creation
required a 3/4 vote *and* no binding vetoes (which I admit makes no sense).
Thanks for the clarification. Ceki



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Ceki Gülcü]

Chris,

I think you are confusing project categorization with project community. These things
are very much unrelated. Regards, Ceki

At 23:44 05.01.2002 +0100, you wrote:
>Hello,
>Each structure has a cost depending on his level of organization. I think
>there is today to many project in the jakarta and the xml project. I feel
>confuse about finding the right information at the right place. And I think
>it's high time to merge xml and jakarta.
>The way java is organizing code in package is rather simple and efficient,
>maybe organizing project this way is the solution.
>We should debate about this organization.
>I propose some package organization :
>
>XML(Xerces,Crimson)
>XSL(Xalan,FOP)
>SVG(Batik)
>WebApps(Cocoon, JetSpeed...)
>JSP (TagLibs)
>FrameWork(Turbine, Avalon, Struts..)
>Project Management (Ant, Slide)
>Metric & Testing (Log4J, WatchDog)
>ToolBox(ORO, RegExp, Lucene)
>...
>I'd like your opinion about it, which package with which existing project.
>
>Ciao
>Chris
>-
>agitateur depuis toujours
>***
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: On unity and coherence [was Re: [Request For Comment] POI @ apache]

[Ceki Gülcü]

At 15:31 05.01.2002 +0100, Stefano Mazzocchi wrote:
[Snip]


>In my mind, all this long trail of thoughs yields the following
>equation:
>
> metacommunity size * community coherence * individual freedom = constant

This equation is misleading. Coherence and individual freedom are 
not inversely proportional, perhaps related but not inversely 
proportional. That much is certain. 
  
>in result, if we unify the two projects, we double the size of the
>metacommunity and we must pay the price of decreased coherence and/or
>decreased individual freedom.

>But are we sure the pros outweight the cons?

No, we can't be sure. The experiment cannot be undone and started
over. 

Anyway, contrary to my previous hints, I am unsure if having XML and
Jakarta would benefit either Jakarta or XML. If someone cares enough
about a particular XML project nothing keeps him/her from participating 
in that project.

IMHO, XML does not and will never have a community as long as two of
its most important projects directly compete with each other. The
success of one is related with the failure of the other. XML
Community? Won't happen in a million years. How the did Crimson
become an Apache project anyway?

Unity and coherence (the subject of this thread) are strongly related to
management and decision making. Since we don't have a manager, we must
have a healthy decision making process.

The current system of voting where each participant is granted veto
power is a system geared towards non-decision making. This was perhaps
one of the intentions of the founders of the ASF. Anyone know where -1
tradition came from?

My suggestion is institute a new tradition where members of the
community can make proposals which the community votes on.

Advantages: decisions can be made.
Disadvantages: decisions can be made.

The required majority for the adoption of proposals can be simple or
qualified. Even if the qualified majority is 3/4, this would be better
than the veto system we have today. Although a veto can be overridden
by a 3/4 majority, as far as I know, this has never happened in the
past.  Today someone voting -1 means end of discussion. 

I dare anyone to -1 that. Regards, Ceki


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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: 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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Jakarta Status [was Code conventions]

[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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>