> According to dependencies.txt, we've got 14 Excalibur subprojects > independent of Avalon.
we do? (...) this is not good. Some of them should probably be reworked to be dependent on the framework. They'll be better for it =) OTOH, they probably have no dependency in code but still a dependency in thought/pattern...I dunno. I didn't write them. For the subprojects where this is not true, they should probably move, except... > Some reasons I think they're not in Commons: > > 1) Pete, Berin and other code authors (who usually do code maintenance) > don't want to subscribe to another list with lots of > unrelated-to-avalon chatter. > 2) Commons "governance" is a bit whacked. Anyone can vote on components > they know and care nothing about. Regularly, committers are expected > to vote on things they know nothing about. I don't know about a lot about how commons is organised. If this is as nonpractical as it sounds from your description, well, commons should be refactored and _then_ the components should move =) > > I'd be happy if they would, we'd just migrate everything over to > > commons, make all of avalon committers to commons, then start work on > > integrating (taking the best pieces of the various implementations and > > "avalonabling" all of it). > > > > The way I see it, Avalon Framework should be in very widespread use > > across the Jakarta and XML projects. > > "should" is a word that sets off warning bells. Who's to judge what > people should spend their free time doing? Should in the sense "it'd be better for those projects, better for jakarta as a whole, better for the world". I believe the same is true for, say, XHTML, ant, javadoc, design patterns. I'm not telling anyone what they should *do*, just how I think it should *be*. > > Commons doesn't see it that way and feels any component that uses the > > avalon framework interfaces as having an ugly dependency on some > > external project. > > Not an ugly dependency, just *a* dependency. If it's got a dep on an > external project, that rather limits it's reusability, defeating the > point of it being in Commons. How does depending on Avalon Framework limit reusability? You'll have a really tough time convincing me here... cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
