On Mon, 10 Nov 2003, Mark R. Diggory wrote:
> Most Commons projects have arisen from either top level apache projects, > xml apache projects or jakarta apache projects. As such they are You'd be surprised that this isn't as common as you think :) Many came out of a junky 'util' project. Struts have been good about factoring out some internal bits, but to a large extent I think the Struts ones are the only ones that have succeeded as spawned projects. Many of the other spawned projects didn't make it out of the sandbox. > I think a great deal of thought has to go into why this sort of > perceived bifurcation is occurring between Apache Commons and Jakarta > Commons. Is there a problem here? Are groups disagreeing with one > anothers written mandates? Or perceived mandates? Do people just not > like working together? Maybe Jakarta needs to issue a more "uptodate" > position on its content? There certainly are allot of non-server It's confusing. I don't think anyone knows yet what the deal will be with A-C and J-C. There's no board-push to move J-C to A-C, and A-C is really just waiting for things to turn up so far. > oriented tools in it, (CLI, Jelly, BCEL, BSF, Gump, Log4j, ORO, Regexp, > JMeter . . .) and there really isn't anything that suggest Jakarta or > the Jakarta Commons are only for Server related packages. What I do see > are different groups of programmers forming separate schools or "clicks". [cliques] :) Do you mean language based? Java vs C vs Python vs Perl? Or internal Jakarta based? Tomcat vs Turbine vs Avalon? This might be a big difference in the httpd/Jakarta world. Jakarta treats 'server' quite liberally while httpd has until recently seemed to focus only on port 80/443 server stuff. > IMHO, the focus now should be on a release of our current efforts in > Jakarta Commons, this will provide a point of reference which we can > grow off of and others can experiment with. It will also get us onto a > more solid release schedule. This was going to be my question when I started replying. Should Math focus on a tight release of what they currently have under the J-C sunshade [as people seem scared of the word umbrella] and then start trying to figure out what thoughts there are for weird and whacky ideas. Seems to be what you're saying, so +1. > We should also consider that we may be working other open source > codebases and projects into the Apache project in the future. We should > expect we are going to eventually need more room to work on such > integration and experimentation outside the scope of what we will want > to make modular and available via the Jakarta Commons. I'm convinced I'd > like to see a "parent project" for the Jakarta Commons Math API, I'm not > convinced yet that it should be outside Jakarta. I think initially, as > least, any parent project of math is going to be very Java centric, we > should take things one step at a time and make changes as they are needed. I think there will be some diplomacy etc to figure out just where a Jakarta Math or Apache Math or Mapache would live. Once the Math release in Commons is made, write a couple of scope documents. One for inside Jakarta and one as a TLP for Apache. See which feels the most comfortable. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
