commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: math to apache commons was Re: [all] Separate email list for math development?
Date Tue, 11 Nov 2003 15:06:36 GMT

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.


>>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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message