Re: Commons Validator Packaging/Content

[Jeff Turner]

On Tue, Jan 08, 2002 at 10:48:42AM -, Danny Angus wrote:
>  Jon wrote:
> 
> > My opinion is that there are to many peers in the process and that is what
> > is breaking Jakarta. This wasn't a problem until now. We are starting to
> > explode under our own ever growing weight.
> 
> I've been involved in other organisations that tried, from best intentions,
> to have a non hierarchical structure.
...

This is a meritocracy. In some projects, the 'merit slope' is so steep
you could ski down it :) Don't let the lack of obvious hierarchy blind
you to the very strong internal hierarchy. Even if people are cheeky to
Jon, they know where on the slope he sits ;)


--Jeff

> 
> d.

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

Avalon, Commons, once again (Re: Commons Validator Packaging/Content)

[Jeff Turner]

On Tue, Jan 08, 2002 at 09:29:18PM +1100, Peter Donald wrote:
...
> > To drive this point home, the subject line of this thread identifies
> > exactly one such set of duplication - between Turbine and Struts.  My
> > nagging lead Berin to propose moving the Avalon collections code into
> > commons, to which you responded, and I quote, "+/- 0".
> 
> I was hoping Jeff would do it as he seemed to be involved over there ;)

I saw the "+/- 0", and that Berin hadn't voted, and then thought of how
this would look to Commons people: as a code "dump"; abandoned by it's
authors, singlehandedly maintained by someone who might disappear at any
moment (from their POV; I'm not going anywhere;). Quite a big ask.

Though if you're okay with it (forking is a bit.. impolite:), I'll make
an attempt sometime late Feb (after holidays.. wheee).

> I have no time atm and no real motiviation to do it. Last time I was
> on the list I watched 3 things be proposed to commons - nobody even
> voted !!! There was no response whatsoever. Apparently Jeff has
> similar comments when he offered some of the avalon bits over there.

'twasn't Avalon code, but yes.. it pains me to think of all those XML
doctype decls flying around, unchanged.. ;)

The lack of project-wide sense of responsibility is the biggest problem
for Commons (and jakarta-taglibs, incidentally). It's something I aim to
help solve the old-fashioned way.

> * I no longer care about duplication and wheel reinvention (it will happen 
> anyway)

Yep, to a degree. Though without a simultaneous commitment to document
the resulting forks/duplications and preferably cull the old code, then
Jon's worst predictions will come true and we can kiss Jakarta goodbye
now. 

> > You can say all you want that you predicted how commons would turn out -
> > but lack of participation by people such as yourself have made such
> > predictions self fulfilling prophesies.
> 
> Heres what sucks about commons;
> 
> 1. People who are not associated with codebase nor ever contributed to it get 
> voting rights over codebase (who needs meritocracy anyways)

Has that turned out to be a problem in practice? Say if you think so,
and we can propose a modification to the charter: "The votes of those
who haven't committed to a project are non-binding".

> 2. Stable packages still have to go via sandbox and go through that whole 
> painful voting process (yet more non-contributors getting votes over codebase)
> 3. Im not a committer

You are. 'donaldp' listed for jakarta-commons and
jakarta-commons-sandbox.


--Jeff

> Change (1) and I will migrate the majority of excaalibur across in time (and 
> bitch and moan till (2)/(3) is changed). Change (1), (2) and (3) and I will 
> move stuff across tomorrow (though still take time to actually do releases).
> 
> -- 
> Cheers,
> 
> Pete
> 
> ---
>  "Remember, your body is a temple; however, it's also your 
>  dancehall and bowling alley"   -- Dharma Montgomery
> ---
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

Re: Avalon, Commons, once again (Re: Commons Validator Packaging/Content)

[Sam Ruby]

Paul Hammont wrote:
>
> There is some romance to extending the 'honor system' to the whole of
> Jakarta.  When we became committers we all treaded tentatively until
> we'd fully earned the respect of the seasoned veterans in the project in
> question.  An 'open' Jakarta would be nice, but even with a code of
> conduct , we'd inevitably get problems with
> incorrect/faulty/inappropriate commits.  How about for those that have
> been here for say two years?

First, this is not an issue that I plan to campaign strongly for.  I doubt
that there is a project or subproject under the Apache umbrella that I
could not get committer status in a relatively short order if I were to
demonstrate a sustained interest in that code base.

Second, a personal side note, possibly humorous to some.  What you
described is pretty much the opposite of how I joined this project.  Tomcat
was plain broken unless you ran on Solaris and with the latest JDK.  Same
thing was true for Watchdog.  Ant was barely useable.  And that was pretty
much all that existed on Jakarta at the time (anybody remember moo?).
Seeing as things were not getting done, and the PMC at the time was very
political and contained a number of non-coder types, I simply went about my
business of correcting what needed to be done.  For a while, I was also the
release manager of all things Jakarta - something that is hard to
comprehend today, but one thing that was for sure, when a release was made
- all the latest versions of everything worked together!

Ant was a particular focus of mine.  For a long stretch, I was essentially
the only committer.  Eventually I found capable successors, and let them
take over.  The reason I bring this up is that my current relation with
that team has evolved.  While I am still a committer, unless I am fairly
certain of what the implications of a change are, I may choose to submit a
patch instead and let someone else determine if my proposed change is the
right way to address a problem.

Third, I happen to have cvsroot authority.  There isn't a codebase around
that, given a sufficient emergency, I wouldn't choose to act first and deal
with the ramifications later.  I don't recall ever having exercised this
authority.

 - - -

Note: none of this contradicts anything you said.  In these circles, I
clearly qualify as a seasoned veteran, and it is exactly because I have
demonstrated enough judgement in these areas that people are willing to
give me more latitude.

- Sam Ruby


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/8/02 3:13 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> so would collaboration on a web framework
> 
> Pete

This happened a long time ago (May 2000) on the PMC list:

When Craig originally proposed Struts, I -1'd it. He assured me that he
would be willing to collaborate together on Turbine and Struts (see the
Third point below), so I changed to a +1 based on that point alone (there is
another message where I made that clear).

Needless to say, Craig lied. So, don't give me anymore shit Peter. I'm tired
of it.

-jon

-- Forwarded Message
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Date: Tue, 30 May 2000 12:45:17 -0700
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL/VOTE] New Jakarta Subproject - "Struts"

Jon Stevens wrote:

> on 5/30/2000 11:19 AM, Craig R. McClanahan at [EMAIL PROTECTED]
> wrote:
>
> > Adding JSP-related stuff into Turbine is also a good idea; it's just not on
my
> > list of interesting things to work on.
> >
> > Craig
>
> Why not just add Struts into Turbine?
>

In my mind, there are several issues:

First, (somewhat paradoxically), is the fact that Turbine does so much for
you. It's comprehensive nature, like any good framework, makes it
correspondingingly tough to get your hands around.  Struts focuses on the
MVC architecture (slightly different approach than Action Events but the
same basic idea) plus the use of some JSP custom tags that interact with the
action classes in synergistic ways.  One of the ways to view Turbine is
"this is what you graduate to, once you understand what an MVC-architectured
web application looks like."

Second, some of the functionality supported by Turbine is done in ways that
differ from the emerging J2EE standards (for example, connection pools).
Granted, you got there first -- but some of the people who want to build
MVC-based web applications will be doing so with a J2EE server as the target
platform, so they will need to utilize the J2EE approach to things like this
where such an approach exists.  This is a philosophy issue for Turbine in
general -- do you want to blaze your own trail in how services are provided,
or do you want to become more J2EE-like?  (I don't have the personal energy
or passion needed to productively participate in this discussion -- that's
for the people who really care about Turbine to decide.)

Third, it is a little early to think that anyone (including myself) has a
clear handle on what the optimum integration of JSP into a full-featured
application framework like Turbine should look like.  One of the ways to
view Struts is "an incubator for exploring how to do Model 2 apps, using
JSPs and custom tags, in an optimum way."  Once the pattern is clear, it
will be lots easier to integrate the final result into Turbine, rather than
doing the integration over and over again as the patterns get refined.

Fourth, over the last year or so on JSP-INTEREST a considerable amount of
discussion has taken place about how to do Model-2 based app designs, using
the fundamental patterns that are implemented in Struts ("similar but
different" to corresponding things in Turbine).  Large numbers of people
have asked for a working example because they are new to the whole concept
of writing web apps (to say nothing of the implications of writing code that
works in a multithreaded server environment :-) -- I wish to meet that need
without making them have to learn too much at once.

Finally, longer term, I would not be at all surprised to see the two
approaches merged.  That just doesn't help meet a short term need to publish
code so that I can stop describing the pattern over and over again in words
on the mailing lists.  A hyperlink to a download is much more concise and
easier to type :-).

>
> -jon

Craig



-- End of Forwarded Message


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

Re: Avalon, Commons, once again (Re: Commons Validator Packaging/Content)

[Paul Hammant]

Sam,

>I have quietly stated several times that I would prefer that a Jakarta
>committer is a Jakarta committer.  Gaging by the response I got each time,
>I figured that then was not the time to push the issue.
>

There is some romance to extending the 'honor system' to the whole of 
Jakarta.  When we became committers we all treaded tentatively until 
we'd fully earned the respect of the seasoned veterans in the project in 
question.  An 'open' Jakarta would be nice, but even with a code of 
conduct , we'd inevitably get problems with 
incorrect/faulty/inappropriate commits.  How about for those that have 
been here for say two years?

Regards,

- Paul H


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

Re: Avalon, Commons, once again (Re: Commons Validator Packaging/Content)

[Sam Ruby]

Ted Husted wrote:
>
> As it stands, both are simply subprojects, and so a Commons committer is
> a Commons committer. Ditto for Taglibs.

It is also fair to point out that an Avalon committer is a committer to the
framework itself as well as to testlet, logkit, phoenix, cornerstone,
excalibur, and site.  So, one could draw a conclusion that anybody who
choses not to participate in Commons due to this structure would also chose
to withdraw from Avalon until this is corrected.

> In a way, the Commons and Taglibs subproject represent the other
> approach to Jakarta that people sometimes advocate, but so far a strong
> leader has not stepped up to fulfill the other half of that model.

I have quietly stated several times that I would prefer that a Jakarta
committer is a Jakarta committer.  Gaging by the response I got each time,
I figured that then was not the time to push the issue.

- Sam Ruby


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

Re: Avalon, Commons, once again (Re: Commons Validator Packaging/Content)

[Ted Husted]

Jeff Turner wrote:
> Has that turned out to be a problem in practice? Say if you think so,
> and we can propose a modification to the charter: "The votes of those
> who haven't committed to a project are non-binding".

That would be a matter to be discussed on the Commons (and/or Tablibs)
lists., 

As it stands, both are simply subprojects, and so a Commons committer is
a Commons committer. Ditto for Taglibs. 

This was discussed at length when the Commons was founded. The consensus
was that since the Commons is trying to build codebases that can safely
interact with each other, then every Commons Comitter has a vested
interest in every Commons codebase. Another point was that the Commons
(and Taglibs) do not require a full community behind each component, and
so other Committers to the subproject need the karma/authority to step
up as needed.

Of course, you do still need to at least be a Committer to either
subproject to have a binding vote. The expectation is that the community
can handle the decision making in the same way it is handled on a larger
codebase, where Committers have binding votes over parts of the codebase
(packages or classes) that they may never have worked on personally. 

In a way, the Commons and Taglibs subproject represent the other
approach to Jakarta that people sometimes advocate, but so far a strong
leader has not stepped up to fulfill the other half of that model.

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

Turbine and Avalon serve very distinct purposes, uses and users.

They just have a load of components trying to do the same thing.

Those could be shared and unified by placing them in the commons.


Have fun,
Paulo Gaspar

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 08, 2002 12:13 PM
> 
> On Tue, 8 Jan 2002 03:04, Jon Scott Stevens wrote:
> > on 1/7/02 2:45 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> > > On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote:
> > >> Peter,
> > >>
> > >> So are you proposing to become a log4j committer?
> > >
> > > Would there be a point to that?
> >
> > 
> > Exactly. Collaboration on a single logging tool would be a 
> terrible idea.
> > 
> 
> so would collaboration on a web framework
> 
> -- 
> Cheers,
> 
> Pete
> 
> -
> Clarke's Third Law: "Any technology distinguishable from 
> magic is insufficiently advanced".
> -


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

Avalon, Commons, once again (Re: Commons Validator Packaging/Content)

[Jeff Turner]

On Tue, Jan 08, 2002 at 09:29:18PM +1100, Peter Donald wrote:
...
> > To drive this point home, the subject line of this thread identifies
> > exactly one such set of duplication - between Turbine and Struts.  My
> > nagging lead Berin to propose moving the Avalon collections code into
> > commons, to which you responded, and I quote, "+/- 0".
> 
> I was hoping Jeff would do it as he seemed to be involved over there ;)

I saw the "+/- 0", and that Berin hadn't voted, and then thought of how
this would look to Commons people: as a code "dump"; abandoned by it's
authors, singlehandedly maintained by someone who might disappear at any
moment (from their POV; I'm not going anywhere;). Quite a big ask.

Though if you're okay with it (forking is a bit.. impolite:), I'll make
an attempt sometime late Feb (after holidays.. wheee).

> I have no time atm and no real motiviation to do it. Last time I was
> on the list I watched 3 things be proposed to commons - nobody even
> voted !!! There was no response whatsoever. Apparently Jeff has
> similar comments when he offered some of the avalon bits over there.

'twasn't Avalon code, but yes.. it pains me to think of all those XML
doctype decls flying around, unchanged.. ;)

The lack of project-wide sense of responsibility is the biggest problem
for Commons (and jakarta-taglibs, incidentally). It's something I aim to
help solve the old-fashioned way.

> * I no longer care about duplication and wheel reinvention (it will happen 
> anyway)

Yep, to a degree. Though without a simultaneous commitment to document
the resulting forks/duplications and preferably cull the old code, then
Jon's worst predictions will come true and we can kiss Jakarta goodbye
now. 

> > You can say all you want that you predicted how commons would turn out -
> > but lack of participation by people such as yourself have made such
> > predictions self fulfilling prophesies.
> 
> Heres what sucks about commons;
> 
> 1. People who are not associated with codebase nor ever contributed to it get 
> voting rights over codebase (who needs meritocracy anyways)

Has that turned out to be a problem in practice? Say if you think so,
and we can propose a modification to the charter: "The votes of those
who haven't committed to a project are non-binding".

> 2. Stable packages still have to go via sandbox and go through that whole 
> painful voting process (yet more non-contributors getting votes over codebase)
> 3. Im not a committer

You are. 'donaldp' listed for jakarta-commons and
jakarta-commons-sandbox.


--Jeff

> Change (1) and I will migrate the majority of excaalibur across in time (and 
> bitch and moan till (2)/(3) is changed). Change (1), (2) and (3) and I will 
> move stuff across tomorrow (though still take time to actually do releases).
> 
> -- 
> Cheers,
> 
> Pete
> 
> ---
>  "Remember, your body is a temple; however, it's also your 
>  dancehall and bowling alley"   -- Dharma Montgomery
> ---
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

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

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

Re: Commons Validator Packaging/Content

[Ted Husted]

Danny Angus wrote:
> In my experience the best compromise is often to fragment the community,
> have lots of small groups where concensus will get the job done, and hang
> these together, but as this is pretty much what we have here already I find
> myself asking the question; what role do the PMC members see for the PMC? Is
> it simply a sub-project charged with developing communication/process
> between sub-projects, or do you want to exert control and leadership over
> the sub-projects?

As a PMC member, it's my feeling that while the PMC is responsible for
the "active management" of the Jakarta Project, we are not directly
resonsible for the active management of the subprojects. Them that make
the code make the decisions. 

As a PMC member, I try to encourage subprojects to work together, but
don't believe that this can be dictated without sacrificing the core
Apache mission:

"to ensure that the Apache projects continue to exist beyond the
participation of individual volunteers, to enable contributions of
intellectual property and funds on a sound basis, and to provide a
vehicle for limiting legal exposure while participating in open-source
software projects."

I believe that the best way to ensure that our Project and subprojects
continue to exist is to allow Meritocracy to work. And I believe that
Meritocracy is working here. 

I also recognize that there is a community within Jakarta that would
like to create a web of strongly-aligned subprojects. I can see why this
would be a good thing, but feel that pursuing ~only~ that goal means
that we will have fewer codebases with fewer committers. This would not
not serve the implicit Apache mission of promoting Meritocracy as a
popular way to manage open source projects.

I was quite sincere when I suggested that perhaps there is room for a
Tigris-style Apache project. As they say, the third time is the charm.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Building Java web applications with Struts.
-- Tel +1 585 737-3463.
-- Web http://www.husted.com/struts/

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

Re: Commons Validator Packaging/Content

[Peter Donald]

On Tue, 8 Jan 2002 03:04, Jon Scott Stevens wrote:
> on 1/7/02 2:45 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> > On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote:
> >> Peter,
> >>
> >> So are you proposing to become a log4j committer?
> >
> > Would there be a point to that?
>
> 
> Exactly. Collaboration on a single logging tool would be a terrible idea.
> 

so would collaboration on a web framework

-- 
Cheers,

Pete

-
Clarke's Third Law: "Any technology distinguishable from 
magic is insufficiently advanced".
-

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

Re: Commons Validator Packaging/Content

[Peter Donald]

On Tue, 8 Jan 2002 21:30, Sam Ruby wrote:
> Paulo Gaspar wrote:
> >> I do what I can at the pace I am able.
> >
> >Which is quite impressive. Especially considering that you probably have
> >other duties and a live.
>
> Thanks.  And I do have both.
>
> http://www.activestate.com/Corporate/People/Tech_Board.html#sam
> http://www.zend.com/zend/hof/sam.php

Damn you get around! :)

-- 
Cheers,

Pete

*--*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."  |
|   -Abraham Lincoln   |
*--*

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

RE: Commons Validator Packaging/Content

[Danny Angus]

 Jon wrote:

> My opinion is that there are to many peers in the process and that is what
> is breaking Jakarta. This wasn't a problem until now. We are starting to
> explode under our own ever growing weight.

I've been involved in other organisations that tried, from best intentions,
to have a non hierarchical structure.
In the end, as they grew, they almost always either:
a) fade away as people get bored with endless discussion of procedure and
leave,
or
b) develop leadership structures which can make snap decisions and represent
the community externally

the problem with "a" is self evident, in the case of Jakarta I suspect this
would (is?) manifesting itself as increasing insularity of the sub-projects.
After all the software is still wanted, its the community that most users
and developers see as a cost or by-product of free stuff, most of us don't
have all that much time to spare on community issues, we also have project
related stuff, jobs, family, beer etc.

the problem with "b" is that it is a "sell out", by appointing leaders we
sacrifice a much loved principle, and ordinary members start asking "who the
hell do they think they are, to speak on my behalf?"

In my experience the best compromise is often to fragment the community,
have lots of small groups where concensus will get the job done, and hang
these together, but as this is pretty much what we have here already I find
myself asking the question; what role do the PMC members see for the PMC? Is
it simply a sub-project charged with developing communication/process
between sub-projects, or do you want to exert control and leadership over
the sub-projects?


d.


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

RE: Commons Validator Packaging/Content

[Sam Ruby]

Paulo Gaspar wrote:
>
>> I do what I can at the pace I am able.
>
>Which is quite impressive. Especially considering that you probably have
>other duties and a live.

Thanks.  And I do have both.

http://www.activestate.com/Corporate/People/Tech_Board.html#sam
http://www.zend.com/zend/hof/sam.php

- Sam Ruby


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

Re: Commons Validator Packaging/Content

[Peter Donald]

On Tue, 8 Jan 2002 01:40, Sam Ruby wrote:
> Peter Donald wrote:
> > > > > So are you proposing to become a log4j committer?
> > > >
> > > > Would there be a point to that?
> > >
> > > It depends on whether and how you want to contribute.
> > > There still is a lot of work to do. Ceki
> >
> > And theres the rub.
>
> These one (or two) line answers don't do much to illuminate the issues.
> Let me try to rectify this:

actually thats not the point I was trying to get across (but an interesting 
one none the less). The point I was trying to get across was about Cekis 
attitude is precisely why Jakarta is the way it is and why it is going to 
only get "worse". 

He has no problem with me working for Log4j but the idea of actual 
collaboration is foreign. Now wouldn't it have been more interesting 
if he had said "lets get together and collaborate on Log4j v2" as you suggest 
or even just sharing the common infrstructure. However he didn't. He wants me 
to work on his project.

I wonder if Jon asked Craig to work on turbine whether he would accept? 
hm I wonder.

> Ceki, fundamental to Avalon is a design pattern that is referred to as
> "Inversion of Control".  This is fairly concisely described at the
> following web page:
> http://jakarta.apache.org/avalon/framework/inversion-of-control.html ,
> including an example which maps this concept into exactly this domain. 

IOC is not really the stop gap - Log4j could easily layered over the top of 
LogKit with very few issues. 

> Can
> you conceive of any possibility where you and Peter could work together on
> a "log4j v2.0" which conforms to what amounts to a set of restrictions on
> what a component can do?  Your answer above indicates that you have
> preconceived notions as to how you would limit Peter's freedom to
> participate.  Care to elaborate?

This is what I initially proposed to Ceki after it became obvious he was not 
willing to enable what we needed. This was a few months before he even came 
to Apache IIRC and I sent him at least 3 different proposals on how to 
integrate our work - though I believe he claims he only received 2. However 
at no stage did he even bother to acknowledge the proposals.

I would be very surprised if Ceki was willing to work with anyone else though 
I could be surprised .. I suspect the answer is "no" though ;)

> Peter, as you are well aware, I'm not overly thrilled with the way that
> Avalon has participated in commons either. 

I weren't aware we were participating ? ;)

> I have been unable to locate an
> adequate archive to point to, but recently I felt compelled recently
> (2001-12-26) to write the following words:
>
>There are quite a few projects under the Apache umbrella that I see as
>simultaneously unwilling to depend on others, and puzzled that more
>people are not willing to depend on them.

And if you recall I agreed with you in a reply ... or at least I seem to 
recall doing so ;)

> To drive this point home, the subject line of this thread identifies
> exactly one such set of duplication - between Turbine and Struts.  My
> nagging lead Berin to propose moving the Avalon collections code into
> commons, to which you responded, and I quote, "+/- 0".

I was hoping Jeff would do it as he seemed to be involved over there ;) I 
have no time atm and no real motiviation to do it. Last time I was on the 
list I watched 3 things be proposed to commons - nobody even voted !!! There 
was no response whatsoever. Apparently Jeff has similar comments when he 
offered some of the avalon bits over there.

I m not willing to do the work for some simple reasons 
* I don't like the management style (see below)
* I am lazy and don't like creating more work for myself (bet you knew that 
already though)
* I no longer care about duplication and wheel reinvention (it will happen 
anyway)

> You can say all you want that you predicted how commons would turn out -
> but lack of participation by people such as yourself have made such
> predictions self fulfilling prophesies.

Heres what sucks about commons;

1. People who are not associated with codebase nor ever contributed to it get 
voting rights over codebase (who needs meritocracy anyways)
2. Stable packages still have to go via sandbox and go through that whole 
painful voting process (yet more non-contributors getting votes over codebase)
3. Im not a committer

Change (1) and I will migrate the majority of excaalibur across in time (and 
bitch and moan till (2)/(3) is changed). Change (1), (2) and (3) and I will 
move stuff across tomorrow (though still take time to actually do releases).

-- 
Cheers,

Pete

---
 "Remember, your body is a temple; however, it's also your 
 dancehall and bowling alley"   -- Dharma Montgomery
---

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

Re: Commons Validator Packaging/Content

[Peter Donald]

On Mon, 7 Jan 2002 20:55, Peter Donald wrote:
> The best way to describe it was something I think Craig said, something
> like - it doesn't much matter if there is an existing project with same
> aims, what matters is what committers are willing to commit to.

err maybe it was Ted ;)

-- 
Cheers,

Pete

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

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

Re: Commons Validator Packaging/Content

[Peter Donald]

On Tue, 8 Jan 2002 12:36, Ceki Gülcü wrote:
> 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?

What a laff! JBoss and Weblogics MBean use is completely and utterly 
different - JBoss uses JMX as a services architecture while Weblogic uses JMX 
as a management interface (you know - what it was designed for). 

The only way that BEA could possibly decide to use the standard 
management interface to manage its server is to see JMX used in a completely 
different manner - I am not sure how I missed that. It really is innovative 
how BEA decided to use the standard management API when it built its 
management interface. They had no idea that JMX was going to be integrated 
into J2EE at that stage - how could they.

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

gotta love experts.

-- 
Cheers,

Pete

---
"Therefore it can be said that victorious warriors 
win first, and then go to battle, while defeated 
warriors go to battle first, and then seek to win." 
  - Sun Tzu, the Art Of War
---

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

Re: Commons Validator Packaging/Content

[Peter Donald]

On Tue, 8 Jan 2002 03:03, Jon Scott Stevens wrote:
> In this email, all I hear you doing is pointing fingers.

It has nothing to do with that. I keep hearing you and other people say 
jakarta is broken. However as far as I can tell it is just talk whenever 
someone steps on your toes. You don't really care when other peoples toes get 
stepped on or when you do th stepping. So how can really expect anyone to 
care about your issues?

> As for me fixing Jakarta...I'm not sure I have enough people interested in
> helping fixing Jakarta. For example, Sam (our current leader) and others
> see nothing wrong with the current process. I'm also not certain I have
> enough energy to fight anymore...especially now that we have so many people
> willing to give their $0.00 opinion and not back that up with action.
>
> Honestly, I'm considering leaving entirely...or at least doing what I see
> everyone else doing...putting their head in a hole and just doing whatever
> the fuck they want to do. Not helpful, but like all of you, I don't have
> time either.
>
> The failure of Jakarta will be in the reality that no one has the time or
> energy to keep it running.

It really doesn't take much energy or effort. It takes a few minor 
compromises by people like yourself. Re: build.xml format again - it was your 
insistence that your way is right and screw everyone else who conflicted with 
you that led me to not bother pursuig it. If jakarta is failing it is because 
of people like you who are unwilling to compromise. 

When I see you change your attitude to match your words then I will be 
interested, till then I just see you whining when someone does to you, what 
you do to other projects.

Anyways personally I have watched this change occur. I would prefer that 
Jakarta conformed to your vision but I don't think it will. So instead of 
seeing it as a failure I prefer to see it a sa different version of success ;)

-- 
Cheers,

Pete

---
Murphy's law - "Anything that can go wrong, will." 
(Actually, this is Finagle's law, which in itself 
shows that Finagle was right.)
---


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 7:30 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:

> I think Jon is undervaluing Jakarta because he helped creating it and
> he is comparing what it is with what he dreamed it would be. Things tend
> not to work according to our high expectations.

I'm sure that is very true.

-jon


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

Ceki, I believe all you say.

However that does not mean that JBoss does better elsewhere than it would
do here.

Jon stated that some non-Apache projects show that there are better ways
of doing Open Source and gave JBoss as an example.

But we just do not know how it would be if they were her.

IMHO, JBoss is much cleaner of nonsense and much easier to get working
than all the other Open Source app servers. That's it - no competition.
It would probably also have no competition at Apache just by having the
same core developers and core orientations (or just most of them).

I just think they always had the best direction by a long way and that
it would be like that anyway.


Orion, although cheap and good, is payware... and I think I would choose
JBoss even if Orion was Open Source (but I am not even 80% sure, much
because Orion isn't OS).


Me thinks Jon must come up with a better example to prove his POV.
Me also thinks it will not be easy since Apache is quite good.

And I am not a Jakarta founder. I took a look around with impartiality.

I think Jon is undervaluing Jakarta because he helped creating it and
he is comparing what it is with what he dreamed it would be. Things tend
not to work according to our high expectations.

I am comparing it with what I see elsewhere.


Have fun,
Paulo Gaspar


> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 08, 2002 2:36 AM
>
>
> 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


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

Answer inline,

> -Original Message-
> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 08, 2002 2:18 AM
>
>
> on 1/7/02 5:18 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> 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 hosted their project on my servers for the first couple of
> years they were
> alive and have had a boat load of conversations with Marc.

You sure seem to be well informed.
=;o)


> > 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
>
> I think it is more than that though...they have worked to develop a
> community and a LOT of interest. At least that is what their website
> suggests. It could be a result of what you say, but Jakarta's
> success isn't
> necessarily because of our projects or our community...it is
> because of the Apache name behind it.

I think you overvalue Apache's name on that and undervalue the quality of
what is done here.

I "moved" here less than 2 years ago and I believe my POV is more impartial
about that, since I was not immersed on Jakarta since day one as you did.


If you want a detail account of how a newbie arrives and stays at Apache:

The fact that Apache made the famous Apache Web server did not motivate me
to get an immediate adept of its Java stuff at all. I thought:
  "So, they have Java. Having people that know how to make a Web server
   does not mean they know how to do anything else. Probably it is not
   even the same people."

But since I had found Apache's Java page by accident, I decided to take a
look. New to web development, JServ did not impress me at all.

I wanted to use Java since Servlets and JSPs looked much better designed
and easier to use than ISAPI Extensions and ASPs (yes... coming from the
MS platform). Servlets looked even simpler and more powerful than using
Delphi for the ISAPI extensions (I did not even consider using VC++).

Since JServ looked so basic, I went on trying JRun (argh! it sure was
buggy) and Sun's Java Web Server (argh! buggy and heavy and slooowww!!!).

I took a look at a load of other Servlet engines. Some were way too
expensive for what they were worth... or it was just not sure at all
they were worth something at all. Others were too basic or fragile.

Then I found out many people saying that JServ was very robust, found
about Tomcat, tried both and started using JServ (and started getting
into flame wars with Jon about TC 3.3 (o;= ).


So I did not come here because of the Apache name, but because JServ
had its own reputation for robustness and because Tomcat was almost
there. (And I tested and played with Tomcat much more than with JServ
to be sure of that.)


It was the same with all other Java software and source code I am
using. I tried to find alternatives everywhere, used Google, spent
hours digging on Java publications and on source code. In the end
most of what I use is Apache again.


I once had a list of around 10 projects/project-families which Docs
and Source I considered worth checking with some detail after a lot
of pre-selection work (which already included taking a look at bits
of code and reading a lot of docs). Among these project families
were big monsters like JBoss, Exolab, Locomotive, etc. I even
subscribed most JBoss lists and some from Exolab.

In terms of the source code I adapted, everything I ended up using
was Apache. Only recently did I integrate a couple of other classes.
Only one non-Apache project taught me something really meaningful
that I really used. (I learned a lot other stuff, of course. But I
am not using it - most of it is JNDI and otherwise J2EE related.)

In terms of libraries, lets take a look at my "lib" directory...
Sun Java APIs, JDBC drivers, a couple of scripting engines (I
recommend Pnuts - damn fast) and Apache stuff again!

A Search Engine and a Logging API used in my company ended up
coming to Apache - Log4J and Lucene.


I currently use LogKit in my stuff, wrapped by (an adapted)
Avalon's common logging interface. One size does not fit all and,
unless one of them changes a lot, I would rather have both.



That I ended up with Apache for almost everything as nothing to do
with the Apache brand. It just has to do with:
 1 - The quality of the product;
 2 - This crazy and brilliant community.


And yes, my eyes are not closed to the world outside Apache and I
keep checking other tools and libraries. But I end up learning
more about good "outside Apache" tools form Apache related sources
than from all other sources together - whic

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 5:36 PM, "Ceki Gülcü" <[EMAIL PROTECTED]> wrote:

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

And just like JSP, it doesn't matter how bad the tool is...if there is
enough people behind it...nothing can stop it...

I actually envy Jboss at this point. They have focus.

-jon


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

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

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



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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 5:18 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> 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 hosted their project on my servers for the first couple of years they were
alive and have had a boat load of conversations with Marc.

> 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

I think it is more than that though...they have worked to develop a
community and a LOT of interest. At least that is what their website
suggests. It could be a result of what you say, but Jakarta's success isn't
necessarily because of our projects or our community...it is because of the
Apache name behind it.

>, unlike Jakarta products like Tomcat or
> Velocity.

Velocity isn't that successful compared with projects like Tomcat or Struts.
There is only 500 people on the -user mailing list and 220 on the -dev
Velocity lists. Of course we don't have Sun marketing backing us though...
:-(

-jon


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

Re: Commons Validator Packaging/Content

[Geir Magnusson Jr.]

On 1/7/02 11:04 AM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:

> on 1/7/02 2:45 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> 
>> On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote:
>>> Peter,
>>> 
>>> So are you proposing to become a log4j committer?
>> 
>> Would there be a point to that?
> 
> 
> Exactly. Collaboration on a single logging tool would be a terrible idea.
> 
> 
> -jon
> 

Whew.  Good thing you noted that it was sarcasm or we never would have
guessed ...

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


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 4:23 PM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:

> if the peers agree with this process.

My opinion is that there are to many peers in the process and that is what
is breaking Jakarta. This wasn't a problem until now. We are starting to
explode under our own ever growing weight.

Jakarta is like a beached whale.

http://www.perp.com/whale/video.html

-jon


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

> I do what I can at the pace I am able.

Which is quite impressive. Especially considering that you probably have
other duties and a live.

I agree 100% with the rest (especially with the mass revolt bit).

Checking mechanisms (automatic or manual) and systematic nagging look 
much more constructive and efficient to me than occasional bursts of
flames.


Have fun,
Paulo Gaspar


> -Original Message-
> From: Sam Ruby [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 07, 2002 9:17 PM
> 
> Jon Stevens wrote:
> >
> > There were no documents like that before I wrote it.
> 
> Forgive me, but I still hold to my belief that that at the time it was
> written, that document wasn't worth the paper it was written on.
> 
> > Just like there was no nag.pl before I came up with the idea to 
> implement
> > it.
> 
> You can believe what you want.  It was part of my master plan.
> 
> > If anything, you initially resisted nag.pl. One way I know this is
> because
> > as the PMC Chair, you refused make it a requirement of projects to have
> it
> > enabled. Instead, you relied on social pressures to work their magic.
> This
> > actually extended the amount of time it took for people to 
> adopt Gump and
> > raise its awareness. It also caused quite a bit of pain (as you say
> below)
> > as projects had votes against it.
> 
> IIRC, your plan was to send nags on succcesses as well as failures.
> 
> Re: mass conversion - I still believe that there would have been mass
> revolt instead.  I do not have enough arms and legs to be 
> everywhere at all
> times.  I have deliberatedly paced the rate at which I have incorporated
> new codebases based on how many battles I felt that I could concurrently
> fight.
> 
> There are quite a few code bases that took a number of iterations before
> the either saw the light or resigned themselves to the fact that I wasn't
> going to relent.
> 
> > Exactly. I feel that this lack of semblance of control from the top has
> > actually hurt us. Looking at the success of other projects which have
> more
> > control at the top makes me realize this. Jakarta to me is now 
> a complete
> > anarchy where people can do whatever they want without having to worry
> about
> > consequences over the long term.
> 
> I do what I can at the pace I am able.
> 
> - Sam Ruby


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

Which projects are those?
Can you really compare them - and their community - with Jakarta?

I just want to know more.


Have fun,
Paulo Gaspar

> -Original Message-
> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 07, 2002 8:16 PM
>
> ...
>
> Exactly. I feel that this lack of semblance of control from the top has
> actually hurt us. Looking at the success of other projects which have more
> control at the top makes me realize this. Jakarta to me is now a complete
> anarchy where people can do whatever they want without having to
> worry about consequences over the long term.
>
> -jon


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

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

I can finally agree with Ceki without restrictions. Peer pressure
is the way... if the peers agree with this process.


Have fun,
Paulo Gaspar

> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 07, 2002 7:54 PM
>
>
> 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:   
For additional commands, e-mail: 

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

> -Original Message-
> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 07, 2002 7:33 PM
>
>
> 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.

Neither I.

I am just defending "popular rule", as imperfect as it is, as the
best system. And also defending the "checks and balances" that
avoid any minority of taking advantage of some hole in the rules
to subvert that "popular rule".

Of course that I am pushing the envelope comparing Apache's system
with a democracy - which it is not and should not become. I just
find that the current meritocracy system works quite well.

It is not perfect, but I believe that enforcing too much
strictness would be counterproductive.

As Sam, I see clear signs of progress. Self organization is slowly
happening. We all want the same - we just need some time to find a
way to achieve we all believe in, which is sometimes a slow trial
and error process.

Knowing well some "pseudo-organizized" companies (having worked
with some in the past) makes me quite sure of this. Organizations
with less discipline often end up being much more productive.

If forcing someone to work in a way he/she does not believe in
(especially in software development) is so inefficient in the
corporate world, where labor is paid, imagine what would happen
here.

Spending more time to achieve agreement trough trial and error is
a small price to pay for the stronger synergies that can be
reached later.

Guidance / coaching / "evangelism" and improved communication
channels can be very useful to make convergence faster, but a
heavy hand will just produce an empty "community".


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

Of course!


Have fun,
Paulo Gaspar


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

Re: Commons Validator Packaging/Content

[Sam Ruby]

Jon Stevens wrote:
>
> There were no documents like that before I wrote it.

Forgive me, but I still hold to my belief that that at the time it was
written, that document wasn't worth the paper it was written on.

> Just like there was no nag.pl before I came up with the idea to implement
> it.

You can believe what you want.  It was part of my master plan.

> If anything, you initially resisted nag.pl. One way I know this is
because
> as the PMC Chair, you refused make it a requirement of projects to have
it
> enabled. Instead, you relied on social pressures to work their magic.
This
> actually extended the amount of time it took for people to adopt Gump and
> raise its awareness. It also caused quite a bit of pain (as you say
below)
> as projects had votes against it.

IIRC, your plan was to send nags on succcesses as well as failures.

Re: mass conversion - I still believe that there would have been mass
revolt instead.  I do not have enough arms and legs to be everywhere at all
times.  I have deliberatedly paced the rate at which I have incorporated
new codebases based on how many battles I felt that I could concurrently
fight.

There are quite a few code bases that took a number of iterations before
the either saw the light or resigned themselves to the fact that I wasn't
going to relent.

> Exactly. I feel that this lack of semblance of control from the top has
> actually hurt us. Looking at the success of other projects which have
more
> control at the top makes me realize this. Jakarta to me is now a complete
> anarchy where people can do whatever they want without having to worry
about
> consequences over the long term.

I do what I can at the pace I am able.

- Sam Ruby


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 10:51 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

> Jon Scott Stevens wrote:
>> 
>> As far as I'm concerned, all Gump shows us is that projects have managed to
>> quit breaking each others interfaces. Gump shows us that documents such as
>> this:
>> 
>>  
>> 
>> ...have had an effect on people's mentalities. Those are not my issues with
>> Jakarta at this point.
> 
> My perception is the other way around.  Documents like that were routinely
> ignored (sound familiar?) until somebody(*) took initiative to find an
> effective way to bring these issues to everybody's attention.  I do have
> all of the published logs archived, and can provide copious examples to
> back up my belief.

There were no documents like that before I wrote it.

Just like there was no nag.pl before I came up with the idea to implement
it.

If anything, you initially resisted nag.pl. One way I know this is because
as the PMC Chair, you refused make it a requirement of projects to have it
enabled. Instead, you relied on social pressures to work their magic. This
actually extended the amount of time it took for people to adopt Gump and
raise its awareness. It also caused quite a bit of pain (as you say below)
as projects had votes against it.

> I also see this as the path to resolving a number of related issues.  For
> example, find or create a style checker tool.  I'll gladly run it nightly
> against all Jakarta code bases and publish the results.  And one by one
> convince each project that it is their best interest for me to nag them on
> it.
> Not everybody realizes it, but getting people to accept nagging on cross
> project dependency failures was an uphill battle.  At least one subproject
> even had a vote on it.

Exactly. I feel that this lack of semblance of control from the top has
actually hurt us. Looking at the success of other projects which have more
control at the top makes me realize this. Jakarta to me is now a complete
anarchy where people can do whatever they want without having to worry about
consequences over the long term.

-jon


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

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

Re: Commons Validator Packaging/Content

[Sam Ruby]

Jon Scott Stevens wrote:
>
> As far as I'm concerned, all Gump shows us is that projects have managed to
> quit breaking each others interfaces. Gump shows us that documents such as
> this:
>
>  
>
> ...have had an effect on people's mentalities. Those are not my issues with
> Jakarta at this point.

My perception is the other way around.  Documents like that were routinely
ignored (sound familiar?) until somebody(*) took initiative to find an
effective way to bring these issues to everybody's attention.  I do have
all of the published logs archived, and can provide copious examples to
back up my belief.

I also see this as the path to resolving a number of related issues.  For
example, find or create a style checker tool.  I'll gladly run it nightly
against all Jakarta code bases and publish the results.  And one by one
convince each project that it is their best interest for me to nag them on
it.

Not everybody realizes it, but getting people to accept nagging on cross
project dependency failures was an uphill battle.  At least one subproject
even had a vote on it.

- Sam Ruby

(*) a significant portion of the credit goes to Jon Stevens who contributed
the initial implementation of what became nag.pl.


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

RE: Commons Validator Packaging/Content

[Craig R. McClanahan]

On Mon, 7 Jan 2002, Ceki Gülcü wrote:

> Date: Mon, 07 Jan 2002 18:56:30 +0100
> From: Ceki Gülcü <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: RE: Commons Validator Packaging/Content
>
> 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.
>

They aren't being dismissed, but the sky isn't falling either.

Perusing Gump's cross reference page is quite interesting:

  http://jakarta.apache.org/builds/gump/latest/xref.html

Just to pick an example of a package I'm involved in, check out the line
for commons-digester:

   ... jakarta-turbine-tdk maven scarab ...

as well as the developers who have recently been adding features and
tests.  That would have *never* happened a year ago (when this code was
inside the Struts community and Commons didn't exist).

The point from Jon that I *do* dismiss is his feeling that there should be
one and only one implementation of any particular functionality -- "one
size fits all" is a very rare phenomenon in my experience, and having some
choice is helpful.


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

We will continue to do what we've done in the past -- reject projects that
only want the "name recognition" value of being under Apache, and don't
have a development community compatible with Apache's style.  That's much
more important than whether it's server-side versus client-side, or in one
repository versus another.

> Regards, Ceki
>

Craig


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

Re: Commons Validator Packaging/Content

[Craig R. McClanahan]

On Mon, 7 Jan 2002, Sam Ruby wrote:

>
>I continue to see the last 11 months as a period of progress.
>

+1

> - Sam Ruby
>

Craig McClanahan


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

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.

-jon


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

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

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



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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 9:53 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote:

>  I continue to see the last 11 months as a period of progress.
> 
> - Sam Ruby

I never said there hasn't been progress. However, I don't think that
progress is enough to keep the Jakarta project from imploding.

-jon


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

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

[Sam Ruby]

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

Take a moment to review the second paragraph of Section 6.3 of
.  Others in this position
may choose to interpret this more liberally than I do.

> As I already said, I also don't think I have enough backing to:
>
>#1. Get voted into being the PMC chair.

   That is something that you could certainly work to change.

>#2. Make enough of a change to help turn Jakarta around from a slow
 spiraling death.

   I continue to see the last 11 months as a period of progress.

- Sam Ruby


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 10:00 AM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:

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

As far as I'm concerned, all Gump shows us is that projects have managed to
quit breaking each others interfaces. Gump shows us that documents such as
this:



...have had an effect on people's mentalities. Those are not my issues with
Jakarta at this point.

-jon


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

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


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

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


Have fun,
Paulo Gaspar


> -Original Message-
> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 07, 2002 5:05 PM
>
>
> on 1/7/02 3:14 AM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:
>
> > I would still prefer having both around.
> >
> > There are users and committers for each that are not
> > willing to move to the other.
> >
> > IMO, community rules.
>
> There is no community. There is projects which have people who follow them
> blindly.
>
> -jon


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

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

Re: Commons Validator Packaging/Content

[Sam Ruby]

Jon Stevens wrote:
>
> As for me fixing Jakarta...I'm not sure I have enough people interested in
> helping fixing Jakarta. For example, Sam (our current leader) and others see
> nothing wrong with the current process. I'm also not certain I have enough
> energy to fight anymore...especially now that we have so many people willing
> to give their $0.00 opinion and not back that up with action.

I certainly see things wrong with the current process, but apparently since
I don't see the same issues that you do as critical, I therefore see
nothing wrong.

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.

Meanwhile, I will repeat something I said on this list three days ago:

   Be forewarned that the Apache tradition is to allow people with enough
   "fire in their belly" to tackle a particular problem that is important
   to them the freedom to do so.  If the problems you see are something
   that you feel need tackling and the only effective way in which this can
   be accomplished is for you to become the Jakarta PMC chair, then I could
   certainly arrange for an election to take place.  I can't guarantee the
   results of the election or the success of your quest, but I can do my
   part to enable you to pursue your goals.

   Think about this for a while, and let me know if this is a path you wish
   to pursue.

- Sam Ruby


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 2:45 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote:
>> Peter,
>> 
>> So are you proposing to become a log4j committer?
> 
> Would there be a point to that?


Exactly. Collaboration on a single logging tool would be a terrible idea.


-jon


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

on 1/7/02 3:14 AM, "Paulo Gaspar" <[EMAIL PROTECTED]> wrote:

> I would still prefer having both around.
> 
> There are users and committers for each that are not
> willing to move to the other.
> 
> IMO, community rules.

There is no community. There is projects which have people who follow them
blindly.

-jon


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

Peter,

In this email, all I hear you doing is pointing fingers. Yes, we fucked up
along the road of learning. That is to be expected. None of us are perfect.
If we hadn't fucked up, we wouldn't be in the situation we are in now. Duh.

As for me fixing Jakarta...I'm not sure I have enough people interested in
helping fixing Jakarta. For example, Sam (our current leader) and others see
nothing wrong with the current process. I'm also not certain I have enough
energy to fight anymore...especially now that we have so many people willing
to give their $0.00 opinion and not back that up with action.

Honestly, I'm considering leaving entirely...or at least doing what I see
everyone else doing...putting their head in a hole and just doing whatever
the fuck they want to do. Not helpful, but like all of you, I don't have
time either.

The failure of Jakarta will be in the reality that no one has the time or
energy to keep it running.

-jon

on 1/7/02 1:55 AM, "Peter Donald" <[EMAIL PROTECTED]> wrote:

> On Mon, 7 Jan 2002 09:15, Jon Scott Stevens wrote:
>> 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.
> 
> Thats because thats what the PMC encourages (you included). If you recall at
> one stage LogKit was proposed as a jakarta project - before Log4j was present
> but the PMC decided to bring Log4j to jakarta instead. When commons was
> started it was because Avalon did not have the right "advertising". Both of
> these things were a vote by the PMC to reinvent rather than reuse.
> 
> The best way to describe it was something I think Craig said, something like
> - it doesn't much matter if there is an existing project with same aims, what
> matters is what committers are willing to commit to.
> 
> It is much more sexier to rewrite something from scratch than it is to work
> with other peoples code. Why is struts a project? Wouldn't it have been more
> productive to the Apache community overall to live side-by-side with turbine
> (same mailing lists and project etc). Essentially struts would have been a
> complete revolution - having them together would have ensured a much higher
> level of cross pollination. Why is Log4j at jakarta? Wouldn't be better if it
> and LogKit were merged? What about the regex engines?
> 
>> 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.
> 
> It is going to get far far far worse - everyone encourages it from the PMC
> down. Reinvent rather than reuse or so the chant goes.
> 
>> 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.
> 
> Correct. Commons is also fun because people not involved with the code have
> voting rights over it. However I do recall you +1'ed it even when I said it
> would end up like this ;)
> 
>> 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.
> 
> Thats because people don't want it. More than half the people at jakarta are
> egomaniacs. Not that this is a bad thing - it can be very productive but very
> few people want to work together because they can get more glory doing it
> themselves.
> 
>> 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.
> 
> If thats what you consider broken then it is broken and it is going to get
> much more broken. The only way to change this is to to vote it. Next time
> someone raises a vote to duplicate an existing project don't +1 it. And don't
> just complain when someone duplicates a part of turbine.
> 
> I would to love to see more working together but I can't see it happening.
> People are not willing to work together - even for basic things. When I asked
> you to change turbines build system to not conflict with patterns in other
> projects your response was something along the lines. We used ant first, this
> is how you should do it, you are wrong - and thats basically when I stopped
> trying to get people to have standard build file format.
> 
> You say you want to "fix" jakarta then pro

Re: Commons Validator Packaging/Content

[Sam Ruby]

Peter Donald wrote:
>
> > > > So are you proposing to become a log4j committer?
> > >
> > > Would there be a point to that?
> >
> > It depends on whether and how you want to contribute.
> > There still is a lot of work to do. Ceki
>
> And theres the rub.

These one (or two) line answers don't do much to illuminate the issues.
Let me try to rectify this:

Ceki, fundamental to Avalon is a design pattern that is referred to as
"Inversion of Control".  This is fairly concisely described at the
following web page:
http://jakarta.apache.org/avalon/framework/inversion-of-control.html ,
including an example which maps this concept into exactly this domain.  Can
you conceive of any possibility where you and Peter could work together on
a "log4j v2.0" which conforms to what amounts to a set of restrictions on
what a component can do?  Your answer above indicates that you have
preconceived notions as to how you would limit Peter's freedom to
participate.  Care to elaborate?

Peter, as you are well aware, I'm not overly thrilled with the way that
Avalon has participated in commons either.  I have been unable to locate an
adequate archive to point to, but recently I felt compelled recently
(2001-12-26) to write the following words:

   There are quite a few projects under the Apache umbrella that I see as
   simultaneously unwilling to depend on others, and puzzled that more
   people are not willing to depend on them.

   > Do I want to increase the Avalon community?  Definitely!  I don't see how
   > moving Avalon code outside of Avalon increases *Avalon's* community.  I can
   > see how it increases *Commons* community.

   Sigh.

   Turbine and Struts are generally polar opposites, but at least they can
   share a set of collections classes.

To drive this point home, the subject line of this thread identifies
exactly one such set of duplication - between Turbine and Struts.  My
nagging lead Berin to propose moving the Avalon collections code into
commons, to which you responded, and I quote, "+/- 0".

You can say all you want that you predicted how commons would turn out -
but lack of participation by people such as yourself have made such
predictions self fulfilling prophesies.

- Sam Ruby


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

Re: Commons Validator Packaging/Content

[Peter Donald]

On Mon, 7 Jan 2002 22:02, Ceki Gulcu wrote:
> --- Peter Donald <[EMAIL PROTECTED]> wrote:
> > On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote:
> > > Peter,
> > >
> > > So are you proposing to become a log4j committer?
> >
> > Would there be a point to that?
>
> It depends on whether and how you want to contribute.
> There still is a lot of work to do. Ceki

And theres the rub.

-- 
Cheers,

Pete

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

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

Re: Commons Validator Packaging/Content

[Ceki Gulcu]

--- Peter Donald <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote:
> > Peter,
> >
> > So are you proposing to become a log4j committer?
> 
> Would there be a point to that? 

It depends on whether and how you want to contribute.
There still is a lot of work to do. Ceki


__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

I would still prefer having both around.

There are users and committers for each that are not 
willing to move to the other.

IMO, community rules.


Have fun,
Paulo Gaspar

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 07, 2002 11:45 AM
> To: Jakarta General List
> Subject: Re: Commons Validator Packaging/Content
> 
> 
> On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote:
> > Peter,
> >
> > So are you proposing to become a log4j committer?
> 
> Would there be a point to that? 
> 
> -- 
> Cheers,
> 
> Pete
> 
> ---
> To fight and conquer in all your battles is not supreme 
> excellence; supreme excellence consists in breaking the 
> enemy's resistance without fighting. - Sun Tzu, 300 B.C.
> ---


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

Re: Commons Validator Packaging/Content

[Peter Donald]

On Mon, 7 Jan 2002 21:33, Ceki Gulcu wrote:
> Peter,
>
> So are you proposing to become a log4j committer?

Would there be a point to that? 

-- 
Cheers,

Pete

---
To fight and conquer in all your battles is not supreme 
excellence; supreme excellence consists in breaking the 
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
---

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

Re: Commons Validator Packaging/Content

[Ceki Gulcu]

Peter,

So are you proposing to become a log4j committer?
Regards, Ceki

--- Peter Donald <[EMAIL PROTECTED]> wrote:
> On Mon, 7 Jan 2002 09:15, Jon Scott Stevens wrote:
> > 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.
> 
> Thats because thats what the PMC encourages (you
> included). If you recall at 
> one stage LogKit was proposed as a jakarta project -
> before Log4j was present 
> but the PMC decided to bring Log4j to jakarta
> instead. When commons was 
> started it was because Avalon did not have the right
> "advertising". Both of 
> these things were a vote by the PMC to reinvent
> rather than reuse.
> 
> The best way to describe it was something I think
> Craig said, something like 
> - it doesn't much matter if there is an existing
> project with same aims, what 
> matters is what committers are willing to commit to.
> 
> It is much more sexier to rewrite something from
> scratch than it is to work 
> with other peoples code. Why is struts a project?
> Wouldn't it have been more 
> productive to the Apache community overall to live
> side-by-side with turbine 
> (same mailing lists and project etc). Essentially
> struts would have been a 
> complete revolution - having them together would
> have ensured a much higher 
> level of cross pollination. Why is Log4j at jakarta?
> Wouldn't be better if it 
> and LogKit were merged? What about the regex
> engines?
> 
> > 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.
> 
> It is going to get far far far worse - everyone
> encourages it from the PMC 
> down. Reinvent rather than reuse or so the chant
> goes.
> 
> > 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.
> 
> Correct. Commons is also fun because people not
> involved with the code have 
> voting rights over it. However I do recall you +1'ed
> it even when I said it 
> would end up like this ;)
> 
> > 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.
> 
> Thats because people don't want it. More than half
> the people at jakarta are 
> egomaniacs. Not that this is a bad thing - it can be
> very productive but very 
> few people want to work together because they can
> get more glory doing it 
> themselves.
> 
> > 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.
> 
> If thats what you consider broken then it is broken
> and it is going to get 
> much more broken. The only way to change this is to
> to vote it. Next time 
> someone raises a vote to duplicate an existing
> project don't +1 it. And don't 
> just complain when someone duplicates a part of
> turbine.
> 
> I would to love to see more working together but I
> can't see it happening. 
> People are not willing to work together - even for
> basic things. When I asked 
> you to change turbines build system to not conflict
> with patterns in other 
> projects your response was something along the
> lines. We used ant first, this 
> is how you should do it, you are wrong - and thats
> basically when I stopped 
> trying to get people to have standard build file
> format.
> 
> You say you want to "fix" jakarta then prove it -
> lets start working together 
> to get even the basic infrastructure common where
> they interface with other 
> projects. So the ball is in your court now ;)
> 
> BTW turbine is/has uploaded components to commons
> that are duplicates of 
> Avalon functionality. ie the exact same thing that
> happened with validators 
> except that turbine is the "purp" rather than the
> "victim" - so should I wail 
> at you now ? ;)
> 
> -- 
> Cheers,
> 
> Pete
> 
>
--
> "Science is like sex: sometimes something useful
> comes out, 
> but that is not the reason we are doing it" --
> Richard Feynman
>
--
> 
> --
> To unsubscri

Re: Commons Validator Packaging/Content

[Peter Donald]

On Mon, 7 Jan 2002 09:15, Jon Scott Stevens wrote:
> 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.

Thats because thats what the PMC encourages (you included). If you recall at 
one stage LogKit was proposed as a jakarta project - before Log4j was present 
but the PMC decided to bring Log4j to jakarta instead. When commons was 
started it was because Avalon did not have the right "advertising". Both of 
these things were a vote by the PMC to reinvent rather than reuse.

The best way to describe it was something I think Craig said, something like 
- it doesn't much matter if there is an existing project with same aims, what 
matters is what committers are willing to commit to.

It is much more sexier to rewrite something from scratch than it is to work 
with other peoples code. Why is struts a project? Wouldn't it have been more 
productive to the Apache community overall to live side-by-side with turbine 
(same mailing lists and project etc). Essentially struts would have been a 
complete revolution - having them together would have ensured a much higher 
level of cross pollination. Why is Log4j at jakarta? Wouldn't be better if it 
and LogKit were merged? What about the regex engines?

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

It is going to get far far far worse - everyone encourages it from the PMC 
down. Reinvent rather than reuse or so the chant goes.

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

Correct. Commons is also fun because people not involved with the code have 
voting rights over it. However I do recall you +1'ed it even when I said it 
would end up like this ;)

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

Thats because people don't want it. More than half the people at jakarta are 
egomaniacs. Not that this is a bad thing - it can be very productive but very 
few people want to work together because they can get more glory doing it 
themselves.

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

If thats what you consider broken then it is broken and it is going to get 
much more broken. The only way to change this is to to vote it. Next time 
someone raises a vote to duplicate an existing project don't +1 it. And don't 
just complain when someone duplicates a part of turbine.

I would to love to see more working together but I can't see it happening. 
People are not willing to work together - even for basic things. When I asked 
you to change turbines build system to not conflict with patterns in other 
projects your response was something along the lines. We used ant first, this 
is how you should do it, you are wrong - and thats basically when I stopped 
trying to get people to have standard build file format.

You say you want to "fix" jakarta then prove it - lets start working together 
to get even the basic infrastructure common where they interface with other 
projects. So the ball is in your court now ;)

BTW turbine is/has uploaded components to commons that are duplicates of 
Avalon functionality. ie the exact same thing that happened with validators 
except that turbine is the "purp" rather than the "victim" - so should I wail 
at you now ? ;)

-- 
Cheers,

Pete

--
"Science is like sex: sometimes something useful comes out, 
but that is not the reason we are doing it" -- Richard Feynman
--

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

Re: Commons Validator Packaging/Content

[Ceki Gulcu]

Sam,

You are right "stop creating new projects" does not
solve the "Validator" problem. However, stopping the
creation of new projects might have long term effects.
The effect might be increased collaboration or
alternatively everyone leaving. It is a
dangerous/stupid/daring (pick your choice) rule
indeed. Regards, Ceki

 

--- Sam Ruby <[EMAIL PROTECTED]> wrote:
> Ceki Gülcü wrote:
> >
> > 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
> 
> Come again?
> 
> Recap: David Winterfeldt innocently began moving
> code from an existing
> subproject that he is a committer to (struts) to the
> commons (another
> existing subproject), unaware that Intake existed
> inside Turbine (a
> subproject that he is not a committer to). 
> Validator has been a part of
> Struts for over a year, and has been independent of
> Struts for six months.
> David became an Apache committer in September.
> 
> How does your proposed solution, i.e., "stop
> creating new projects" solve
> this problem?
> 
> - Sam Ruby
> 
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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

Re: Commons Validator Packaging/Content

[Sam Ruby]

Ceki Gülcü wrote:
>
> 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

Come again?

Recap: David Winterfeldt innocently began moving code from an existing
subproject that he is a committer to (struts) to the commons (another
existing subproject), unaware that Intake existed inside Turbine (a
subproject that he is not a committer to).  Validator has been a part of
Struts for over a year, and has been independent of Struts for six months.
David became an Apache committer in September.

How does your proposed solution, i.e., "stop creating new projects" solve
this problem?

- Sam Ruby


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

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



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

Re: Commons Validator Packaging/Content

[Kurt Schrader]

On Sunday, January 6, 2002, at 08:48 PM, Martin Cooper wrote:

> If we had known of the existence of Intake before today, we might have 
> gone
> down that path. However, as Intake is apparently currently buried in the
> depths of Turbine, how would we have known? Certainly the Turbine folks
> haven't mentioned it up until today in any of the validator discussions 
> on
> this list, and surely you can't be the only Turbine developer on this 
> list.

I'll bite.  :)

The first problem here is that no one mentioned the Intake framework 
most likely because it's already a fully functional validating 
framework.  It's not an excuse, just a fact.  My pages are already 
validating, so why would I get in on a discussion concerning how to 
write a validator? :)

It's the old limited bandwidth thing again.

With that out of the way, I have no problem with someone merging the two 
now that yours has been brought forward, but I think the question is of 
who (if anyone) the onus should be on to do so.  I'd like to think that 
if Commons functions the way its supposed to then your validator will 
eventually grow to be so much better than Intake that we'll have no 
choice but to move over based upon the advantages offered to us by 
it.  :)

Another problem here is that it's not entirely clear what most of the 
stuff under the Jakarta banner does.  Try this simple experiment: walk 
up to a developer that's not familiar with Jakarta and ask him/her what 
they think each of the following pieces of software does: Turbine, 
Fulcrum, Torque, Etc. (I'm picking on the projects that I work on, but 
clearly almost every project in Jakarta falls under this heading.)  If, 
on the other hand, projects were named with respect to their function, 
then much of this problem would be alleviated.

It's too late for functional naming now, of course, but perhaps each 
project that gets accepted from now on needs have to have an explicit 
declaration of what it does attached to its name.  (e.g. "POI - The 
Jakarta Office File Format Reader/Writer")

This problem is even worse in the Commons and in the Commons-Sandbox.  I 
think that it may be a good idea to require a declaration of purpose in 
a standard file in the top level directory of the project for things 
that are placed in the Commons-Sandbox from here forward.  Hopefully 
these can all be pasted together in some way using Anakia/XSL/Your 
Favorite Tool so that there is an easy way to figure out what everything 
there is supposed to do, much like the new front page for Jakarta.  We 
keep saying that we don't want commons to become SourceForge 2, but 
currently there is nothing to prevent someone from dumping any old code 
there in hopes of it finding a home.  Digging through the mess that it 
is quickly becoming is only going to get harder in the future unless we 
establish some standards for it now.

Finally, I hope that we never grow so large that we forget that the core 
of Jakarta, as I see it, is the people involved.  This clearly wouldn't 
be as much fun if everyone didn't either love/hate Jon, the Tomcat teams 
didn't flame each back and forth occasionally, and everyone didn't have 
Sam's Gump reminders being flung at us.  ;)  This is clearly as much 
about working and forming a community with some of the smartest people 
around as it is about writing great software.

-Kurt


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

RE: Commons Validator Packaging/Content

[Andrew C. Oliver]

You need a search engine for these "little things" maybe off the main
page.  With something catchy under it like "High your software has
already been written for you...find it here".  This would ecourage
useful javadoc comments as well.  So if I type "tree" I should see all
the tree classes in the collections stuff under commons for instance.  

Its useless to say "reuse" when "reuse" implies finding it which implies
knowing where to look for it.  You're expecting people to go through
each and every project and say 'humm is there a TreeMap that does
key->value and value->key here ...nope let me search through the rest of
all the projects'...

I here there is a java indexing package on sourceforge that could be
used for this :-D  (j/k)

-Andy

> Hi Jon,


> I think there is reason for the concern you are raising. I see a lot
> of other work repeated in other sub-projects too.

> Commons seems to be the only place where such smaller simple use
> components are visible. Most people just search there before and
> most think that Turbine and Avalon are big blocks of indivisible
> code.

> Maybe the way to go is just to move such components to the Commons.
> Why not moving Intake now?

> Maybe this issue needs regulation, but this kind of think tends to
> work better if you use the carrot before applying the whip.
> =;o)

 
> Have fun,
> Paulo Gaspar

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


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


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

RE: Commons Validator Packaging/Content

[Paulo Gaspar]

Hi Jon,


I think there is reason for the concern you are raising. I see a lot
of other work repeated in other sub-projects too.

Commons seems to be the only place where such smaller simple use
components are visible. Most people just search there before and
most think that Turbine and Avalon are big blocks of indivisible
code.

Maybe the way to go is just to move such components to the Commons.
Why not moving Intake now?

Maybe this issue needs regulation, but this kind of think tends to
work better if you use the carrot before applying the whip.
=;o)


Have fun,
Paulo Gaspar


> -Original Message-
> From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 06, 2002 11:15 PM
> To: Jakarta Commons Developers List
>
>
> 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:

For additional commands, e-mail:



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

Re: Commons Validator Packaging/Content

[Sam Ruby]

Jon Scott Stevens 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?

Do it in the other way around (make it framework independent, then move it
into commons) and I think you may have a winner.  Meanwhile, it is probably
fair to assume that OTHERS will assume burying gems deep into the fabric of
your component is done for a reason.  In particular, the assumption will
likely be that the code is so intricately interwoven into the fabric of
your component that it would be difficult to break out.  I know that there
are examples of pre-gump days when attempts were made to break things out
that weren't successful; but then again, that was before there was a tool
that helped people monitor the stability of the interfaces.

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

It is also easier to add a code directly to a subproject then to invest the
extra effort in making the code a standalone, reusable component.



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

Oh, there are definately a few things that need fixing around here.  Spend
a few minutes looking at
http://jakarta.apache.org/builds/gump/latest/xref.html .  Tell me what
patterns you see.  I see definate cleaving lines, and they are not along
any of the functional or scoping boundaries that we have been discussing
lately.  The good news is that these lines are getting harder to see every
day.  My current favorite example of a recent closing of one of the
fissures: jakarta-velocity-tools/struts.  Another favorite of mine is
jakarta-commons/collections, followed by jakarta-commons/beanutils.

- Sam Ruby


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

Re: Commons Validator Packaging/Content

[Jon Scott Stevens]

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