commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Commons/Avalon [was Re: [Logging] [VOTE] Commons Logging 1.0 Release]
Date Tue, 29 Jan 2002 23:38:33 GMT

On Wed, 30 Jan 2002, Peter Donald wrote:

> On Wed, 30 Jan 2002 09:11, wrote:
> > Is there a fundamental clash of philosophies between the two that is yet
> > to be resolved? Is it resolvable?
> The main difference is that you should not be able to vote on things you are
> not a developer on. Other than that it is largely window dressing differences.

I'm not sure I get this. A patch to a system makes sense, the developers
on a project will not want a bad patch or a misplaced patch to be added.

But a new release of something, or even a new project will nearly always
be voted for by the developers as +1? Where's the controlling negative

How does this work in Avalon? Someone coding the jdbc-utility part decides
they want to declare a new version for it and the person writing the
logging part is unable to argue because they don't code or use the
jdbc-utility part? I guess that could work fine. Or is there a management
structure to handle that kind of thing?

> > My understanding so far is that Avalon is a standard framework for
> > server-side applications, providing a set of common components to assist
> > in that framework.
> >
> > And that Commons is a set of common components for use in any framework.
> Well you understanding is wrong ;) But quite a few people have made an active
> effort to make you believe that so it is forgiveable. The majority of Avalons
> components are framework agnostic or have framework agostic base classes.

I'm happy to believe that. Good coders like to do that kinda thing and I
expect Apache coders to be good coders. I guess the difference is more in
the stated target of those components? As a dumb component user, would I
be likely to come across an Avalon component and think of using it
separate from the whole structure? Are Commons and Avalon different
marketing ploys?

> Go back to the initial discussions about commons and you will see that its
> current structure was advocated by an AValon developer and that is based on
> the structure of the Avalon component repository ;)
> > Avalon predates Commons, but has a less bazaar like atmosphere(?).
> I wouldn't say that. Most things are go there. We have had different
> implementations of things at different times (4 pool architectures
> simultaneously were present) but the only difference is that in the end we
> tend to work together more and merge bits together.

*nod*. Is Commons moving towards that from your point of view, ie) is it a
maturity of project thing?

Sorry for all the questions, there's a lot of implicity history in these
discussions for newcomers to pick up..


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

View raw message