On Mon, Dec 24, 2001 at 10:04:52AM -0500, Berin Loritsch wrote: > Sam Ruby wrote: > > >Berin Loritsch wrote: > > > >>I have a feeling when all is said and done we will have the following > >>distributions: > >> > >>excalibur-component.jar (container, component, logmanager) > >>excalibur-datasource.jar > >>excalibur-xml.jar (xpath, parser, xslt object, etc.) > >>excalibur-url.jar (source, resource, etc.) > >>excalibur-async.jar (monitor, event, etc.) > >> > > > >Don't forget clutil. > > > >My two cents: if you have componentry which you are willing to split out > >that does not have significant dependencies on any particular framework, it > >will likely get greater visibility and usage if it is in either > >jakarta-commons or xml-commons. > > > >I do believe that people really want to reuse already coded and debugged > >components. It is when such components come with strings attached that the > >hesitation begins. > > > Understood, another issue comes when using code not developed with Inversion > of Control in an environment designed for Inversion of Control. All the > benefits of that design principal/pattern are lost.
Like using LogKit for non-IoC projects.. awkward compared to log4j. > The only time you can mix the code is when the environments are sufficiently > decoupled. > > Also, I would like to see some usage stats for Jakarta Commons. Honestly, > your argument is under the supposition that Commons is more popular or well > known than Avalon. Arguably, Avalon has had a little more press as we have > been "advertising" releases to a number of different news portals. I gather that 'stats' will be part of the new xml.apache.org: >> The log scanner is a set of scripts that scan the logs from the CVS, the >> mail lists and the web site to gather information on: >> >> 1) mail list activity (subscribers and messages) >> 2) web site activity (hits and downloads) >> 3) CVS activity (general commits, commits per person) Unfortunately there are no mbox archives for Commons when the list was called 'jakarta-commons' (see http://jakarta.apache.org/mail/). But some stats anyway: - In November, commons-dev got 314k traffic (.tar.gz'ed), whereas avalon-dev + avalon-cvs got 1375k. - So far in December, commons-dev has 2.2mb, avalon-dev+cvs has 5.8mb. Looking at my personal archive, since 27/8/2001 when I did a 'mail roll', here's the size rankings: -rw------- 1 jeff jeff 43867180 Dec 25 11:09 tomcat-user -rw------- 1 jeff jeff 37856529 Dec 25 11:09 avalon-dev -rw------- 1 jeff jeff 35384868 Dec 25 11:09 cocoon-dev -rw------- 1 jeff jeff 32861870 Dec 25 11:09 struts-user -rw------- 1 jeff jeff 32397108 Dec 25 11:09 tomcat-dev -rw------- 1 jeff jeff 26083583 Dec 25 11:09 ant-dev -rw------- 1 jeff jeff 19062964 Dec 25 11:09 cocoon-users -rw------- 1 jeff jeff 14521851 Dec 24 22:17 ant-user -rw------- 1 jeff jeff 14306228 Dec 25 12:40 jakarta-commons -rw------- 1 jeff jeff 8657045 Dec 25 11:09 struts-dev -rw------- 1 jeff jeff 7226093 Dec 25 11:09 velocity-user -rw------- 1 jeff jeff 5030923 Dec 23 16:47 log4j-user -rw------- 1 jeff jeff 4869238 Dec 22 09:44 taglibs-dev -rw------- 1 jeff jeff 4388551 Dec 25 11:09 xml-general -rw------- 1 jeff jeff 2589660 Dec 24 13:04 jakarta-general -rw------- 1 jeff jeff 1839254 Dec 24 18:10 log4j-dev -rw------- 1 jeff jeff 1369219 Dec 23 11:07 taglibs-user -rw------- 1 jeff jeff 257795 Nov 15 21:53 alexandria-dev So avalon is doing pretty darn well :) *And* that's without the avalon-apps list, which I forgot to subscribe to until recently. Of course, a better way to estimate community size is the number of unique posters to each list. So I wrote a little script to determine this: for i in *; do cat $i | formail -s formail -X"From:" > $i-posters cat $i-posters | sort | uniq > $i-posters-uniq done Here's the revised list: [EMAIL PROTECTED]:~/Mail/apache$ for i in `ls -S1 *-posters-uniq`; do > echo `cat $i | wc -l` $i > done 2491 tomcat-user-posters-uniq 1356 struts-user-posters-uniq 786 cocoon-users-posters-uniq 678 ant-user-posters-uniq 516 tomcat-dev-posters-uniq 322 log4j-user-posters-uniq 317 xml-general-posters-uniq 289 ant-dev-posters-uniq 267 cocoon-dev-posters-uniq 261 velocity-user-posters-uniq 206 struts-dev-posters-uniq 158 jakarta-general-posters-uniq 162 avalon-dev-posters-uniq 159 jakarta-commons-posters-uniq 109 taglibs-user-posters-uniq 106 taglibs-dev-posters-uniq 102 log4j-dev-posters-uniq 21 alexandria-dev-posters-uniq 17 xml-commons-posters-uniq Avalon is way down. Conclusion: Avalon is a small project with some *very* prolific developers :) If there were medals for commitment, Pete, Berin, Paul and co would be getting them all. Back to the issue at hand, Avalon and Commons are almost identical in terms of community size. I'm guessing that Commons people are a much more eclectic bunch, whereas Avalon's constituency reflects it's Cocoon roots. [..] > There are however a number of utilities that would be easily placed in > Commons. > The following packages do not have direct ties to Avalon: > > cli (Command Line Interface) > collections (Buffer and other utilities) > concurrent (semaphores, mutexes, etc.) > io (file, stream, and other IO utilities) > pool (pool interfaces and implementations) > event (event queues--scratchpad) > profile (intrumentation of code--scratchpad) > vfs (virtual file system--scratchpad) > thread (thread pool--scratchpad, dependant on pool) > util (various utility classes--scratchpad) > i18n (ResourceBundle utilities, and an XMLResourceBundle in scratchpad) > > > Those are the only things I can see _possibly_ moving in that direction. > > While this does seem like alot, there are also some other things we must > consider. First and foremost, we would no longer be in control of their > development life. Because some of these pieces (pooling, thread pooling, > concurrent, and collections to name a few) are so critical to the way > things work in Avalon, it is a scary thing to give up that control. The evolution of Commons has been interesting. I don't think it has met it's original goal of cross-project sharing, but it has had some hugely beneficial effects: - exposing bite-size APIs from existing projects, for public use (beanutils, digester, httpclient etc) - acting as a project sandbox, in which established contributors can publicise previously homeless code, in the hopes of it gaining a community (latka, jxpath, etc). It's become a jakarta-flavoured mini-sourceforge, and that's a *good* thing. So in practice, I think the only effect of moving code from Avalon to Commons would be to expose it to a different, same-sized, but more diverse, audience of users, implicitly acting as advertising for Avalon (which is still rather insular IMHO). It would be highly unlikely that "we" lose control, any more than James could lose control of jxpath, or MorganD/RodW lose control of latka. Of course, it *could* happen, and did happen in the case of httpclient, where the API got changed under the feet of the Slide people. In that case, we do what Remy &co. did; complain :) And it all got sorted in the end. > Some things like CLI might make a good contribution, and someone may really > improve the internal architecture, and parameter parsing capabilities (i.e. > make it able to interpret GNU style parameters, POV-Ray style parameters, > etc). James Strachan recently committed werken.opt to the Commons sandbox, illustrating that if Avalon doesn't take the initiative by moving stuff to Commons, code will materialize from somewhere else. Take a look at: http://jakarta.apache.org/~jvanzyl/stratum-proposal.txt cache, configuration, lifecycle, pipeline, pool... it's like a second Excalibur, only without the IoC emphasis. > The problem is that if the interfaces change, that change will affect a > number of different projects: Phoenix, Cocoon, Axis, and JAMES to name > a few. > > I would like to get the concensus of the Avalon team before considering > such a move. That move will change the package names (allowing us to get > rid of cruft and remove deprecated methods and classes in the process). > > Here are the issues I see with this move: > > 1) I personally don't have the energy/time to support yet another project, > but I can support these utilities where they are now. > 2) I already receive over 125 emails between 5:00pm and 8:30am the next > morning due to the mailing lists I subscribe to. Another list with all > the associated noise is not really feasible. Commons gets significantly less mail than Avalon. 14 messages/day, including CVS commits. > 3) These utilities could possibly die in commons, where they would survive > in Avalon. They'd only die if Avalon people abandon them. Otherwise, exposure to a different user group can only be beneficial for the code in question. Interface stability is the thing to watch, though. > 4) Commons could so tightly integrate the utilities that they no longer > able to be used without additional cruft we have no interest in. We'd have to get the Avalon logging interfaces accepted in jakarta-commons/logging, or there'd be immediate conflict. Other than that, I think Commons subprojects are quite self-contained. It's very much up to the people at the top of Avalon's (very steep) meritocracy :) --Jeff > Admittedly, some of these are FUD on my part, but they are real > concerns that I have, and they need to be allayed before I can support > a decision to move Avalon code outside of Avalon. All the other > pieces are either Avalon Components, or support the Avalon > architecture, so they will never be considered for integration with > Commons. > > -- > > "They that give up essential liberty to obtain a little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
