At 10:58 31/1/01 -0600, Randall J. Parr wrote: >I would argue that ORO, RegExpr, even Log4J are just as much out of scope as >Ant. > >I would prefer to see development tools and packages such as these migrate to a >common Apache "dev", "tools", "base", whaterver project. > >I would like to see that project expanded to include packages to handle some of >the common problems such as configuration/property handling that I see being >solved over and over again in the different Apache projects.
Hey ! Come join us then ! ;) Over at Avalon (@java.apache.org/framework) this was one of the original aims of the project. However it kinda lost focus and grew beyond that. We are in the process of refocusinf it and splitting up the different components so that the stable part could be reused in other projects. At one stage I believe JDD was suggesting starting a project AUT (Apache Utility Toolkit or something) that housed all the API level reusable code. ie MD* manglers, CascadingThrowables, StringUtils, CLI parsing etc. I keep poking fellow Avalon members with this so hopefully someone will initiate it. Then we could move stuff from turbine/avalon/other into it. Avalon is meant to be the repository of "framework" level reusable. Whats the difference between framework and API levels - mainly framework enforces a certain structure on user while API level doesn't. The new Avalon once it gets to jakarta will be reduced to do just that task. When it is suitable stable and offers significant advantage I do plan to advocate it to other projects but that is the future ;) >Further, I would like to see a preference (not a rule) for Apache projects to >use these common development tools. As someone stated in another message, when >Apache includes log4j that says to me (maybe incorrectly) Apache thinks this is >the package to use (at least one of the best to use). It is very frustrating to >see Apache projects, even subprojects in the same project all using a different >methods to handle configruation and logging. It really raises the learning curve >for using the software and raises the learning curve for contributing even >higher. It would be nice but it is not always possible ;) People work on what they feel like. You can not force them to adopt something someone else did - especially when they spent ages building it. Some of the projects overlap but have significant differences/points of difference. ie Why do we have two regex libraries here? Some are legacy issues (ie I built a log4j-like logging system before it was Apache sanctioned). Some are just competition or different thinking (Cocoon2 actions vs Turbine actions). However I do think that a consistent build process and directory structure would be of great use. That was the biggest complaint I received when pushing Apache stuff. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
