Henri Yandell wrote:
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.
hmm, I see
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.
Yes, this is what I'm concerned about.
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] :)
Yes Mrs. Smith, my Spell checker ate my English homework...
Do you mean language based? Java vs C vs Python vs Perl? Or internal Jakarta based? Tomcat vs Turbine vs Avalon?
It seems there is a general movement in ASF to propagate some of the concepts and designs associated with Jakarta and XML projects out to all ASF projects as a whole, unfortunately this is translating into a number of different initiatives that appear to be stepping on each others toes.
Apache Incubator vs. Apache Jakarta vs Apache Commons vs Apache XML vs Apache Avalon vs Apache DB
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.
yes
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
Sounds like a good way to move forward.
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
