> Does this mean that we have a project with an XMLConfig component that
> will be used by Avalon and Struts, or will there now be three? :)
And of course, there is the XML config tool from tomcat3.x and the xml
config from ant. Both of them have minimal dependencies on the rest of the
project ( none for tomcat, log/getProperty for ant - but easy to remove ).
So at least 4 to choose from.
How do you choose ? Majority ? But an un-informed majority can't make the
right decision - and few people have used more than one.
That's why I think it is essential to:
1. Allow multiple implementations. Nobody can make the right decision
without all the information - and in some cases different solutions may
have different use cases.
What is important is to have the general-purpose code clearly identified
and in a common place ( because that's the only way we can make sure it
doesn't have hidden dependencies and is indeed reusable ). And it's
important to let time and users to select - instead of making arbitrary
decisions.
2. Each component should have as commiters the union of (interested
!) commiters from the projects that are using it. It's about having -1
control over incompatible changes and having a way to influence the
evolution of the component - each project has specific needs, and the only
way to get a component that can be shared is to make sure that all parties
are represented.
That's why I think having a group of commiters for each component (
selected with any other mechanism ) is bad - the goal is to share
components, and that can't be done if we don't share control.
I don't think the goal is to develop components - we already do that.
The problem that started all this was that components are not shared (
by projects that develop them ) and are not reused ( by projects that
choose to replicate ).
Maybe we should first agree on the goals, before choosing the methods.
Costin
