Jeff Turner wrote: > 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.
They are different mindsets. But it is more awkward trying to force Log4J into the IoC pattern--because you have to hide all the different access points that it gives you. >>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: It is something that they are working towards. > 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: > 159 jakarta-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. To be more precise, it is the other way around. Avalon was first, and Cocoon had a snapshot of Avalon being in it's CVS. > 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: :) It seems that Avalon hasn't either. Avalon's charter was to be the architectural core of all server side Apache projects--it succeeded for some projects, but not for others. > - exposing bite-size APIs from existing projects, for public use > (beanutils, digester, httpclient etc) I have no problems with exposing "bite-size" APIs--which is why I gave the list I did. > - 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. I know alot of people who would be on both sides of that argument. :). > 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). That's not for a lack of trying. > 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. That's a headache that *I* don't want to deal with. However, I listed the packages so that the Avalon committers can *vote* on whether we want to take this action. >>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. Ok, that I do *not* understand. We already have a framework project, and that's Avalon. If the authors want to work on a framework work on this one. When I see multiple projects all with similar lifecycles, using different libraries, and thus uncompatible it makes me sick. >>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. I already spend an hour a day answering Apache mail--and that's ignoring a bulk of it due to time constraints. I don't have the time to _police_ the mails and make sure noone is talking about changing the Avalon originated utilties' API. >>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. So you just made my argument for me. Excalibur code is exposed to another rather large group (Cocoon), it is also rather well tested because of the number of users in that group. > > Interface stability is the thing to watch, though. And that is my biggest concern. If you can succeddfully allay that fear, I might champion the move. > > >>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. The Logging interfaces are going to be fiercely guarded. If *any* additional method is proposed for the logger--it will be strongly recommended that it be a new interface. > It's very much up to the people at the top of Avalon's (very steep) > meritocracy :) It's not that steep, it just seems that way. We have rough edges with our personalities, and sometimes that scares people off. -- "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]>
