commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject Re: math to apache commons was Re: [all] Separate email list for math development?
Date Tue, 11 Nov 2003 07:48:05 GMT


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message