Sam, >Another perspective is that inter subproject sharing at a granularity lower >than the subproject has rarely been successful. > >Things originally identified as reusable components often ended up getting >dependencies on ever increasing portions of the subproject. > >At the time commons was created, Avalon was notorious for changing >interfaces without even so much as a moments notice. The rationalle given >was that Avalon was still in alpha - interminably so. > I am not sure that is so correct. There have been refactorings, but old abstractions were kept as deprecated for quite while.
>The only way a developer who dependended on the component could get a say >in the matter was to become a committer in the subproject at large. In the >case of Avalon, this meant becoming a committer to the entire framework: >jakarta-avalon, jakarta-avalon-testlet, jakarta-avalon-logkit, >jakarta-avalon-phoenix, jakarta-avalon-cornerstone, >jakarta-avalon-excalibur, and jakarta-avalon-site. In other words, they >were required to follow an "absurd rule allows people to vote on something >they dont use/develope and never plant to use/develope." > With respect, all the above are a single commit right. I could be wrong on jakarta-avalon-site through, but that is not relevant to this discussion. Avalon people willfully accomodate the needs of JAMES and Cocoon people inside Apache and plenty of those interested outside Apache. We frequently reach out to other teams in very polite, respectful and concilliatory terms. >So commons was created. It is explicitly designed as a place for people >who "play well with others". And after some initial growing pains appears >to be working. > - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
