> I can see some good use of an apache-commons : > > 1) Projects that are implementing eg RFC's that is not language related > can commonly discuss implementations, have their API's (where usefull) > about the same. > 2) Joining expertise > 3) Clear for the outside : want an http common implementation go to > http://blah and you find all the possible implementations there
Part of the issue is about the different *types* of (sub sub) projects we have in (jakarta) commons. Collections/IO/Util/Pattern/Lang potentially make quite a close group (eg. same committers). JXpath/CLI/HttpClient are much more independent of each other, just sharing the same space (eg. different committers for each). Apache commons doesn't help this, it makes it worse. > 1) Decisions will be a great pain, unless the specific languages can > acutally make decisions on their own. > 2) It can get messy in ML's with language specific issues, not even > speaking about not very interesting commits from the c part of the > project I would set my mail filter so all C and Perl messages go straight to trash. > apache-commons should be there for the outside and for joining > expertise, so mainly containing a website + mailinglists. > This way nothing changes, just some things get added. > The problem with this can be however who will bring parties together in > such an effort ;)) Now, if Apache Commons were 1) Just a 'federation' of commons type Apache projects (as per the original reorg proposal) 2) Not called commons that'd be just grand. Stephen -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
