commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: Apache commons [was:Re: Naming issues]
Date Mon, 21 Oct 2002 22:55:17 GMT
> 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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message