On Wed, 30 Jan 2002, Peter Donald wrote:
> On Wed, 30 Jan 2002 09:11, [EMAIL PROTECTED] 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
factor?
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..
Bay
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
