J.Pietschmann wrote:
Tim O'Brien wrote:
so - is there a positive alternative? i'd like to propose that common-maths continues to be affiliated with jakarta-commons but becomes managed by apache commons.
+1, I think that now is the right time to move commons math to
Apache Commons.
As long as [math] focuses on Java, I don't see what this will buy. If it's simply the commons list becoming too crowded, decide where [math] should go: 1. A companion to [lang], [logging] and [cli], valuing "small" over completeness and focusing on common tasks -> stay at jakarta-commons
2. Grow into a full fledged library or even a system of apps related to numerical calculations -> become a stand-alone Jakarta subproject, or even go top-level.
J.Pietschmann
I suppose I should clarify my opinion on this. Sorry if this is long winded and somewhat confusing. Also, it is just opinion...
Most Commons projects have arisen from either top level apache projects, xml apache projects or jakarta apache projects. As such they are basically refactorings of codebases within those projects. As such, they provide a "unique subset of functionality" from those projects refactored and made available to the community as a whole via the Jakarta Commons. This is a very powerful mechanism and one which the Jakarta Commons is highly tailored for.
To stick my neck out there: While some projects within the Jakarta Commons are uniquely evolved out the sandbox, it is clear that ultimately the best refactorings tend to arise after some considerable mucking about in larger projects with "pre-existing applications" of those code bases as "working proofs of concept".
Interestingly, this mucking about tends to be a bit more revolutionary when one is an independent project with room to both evolve and reinvent its codebase. This, in my opinion is what the math project is lacking by being only within the commons, some wonderful inventions could arise if theres more room to experiment and redesign, if theres room for Math "subprojects" and experimental endeavors such as Interpreter Frameworks, GUI Tools, MathML/OpenMath experimental implementations, usage byte code optimization tools...
These are all things, which in my mind, don't have the space to grow as a simple jakarta commons library, but are vehicles for which a simple jakarta commons library would take its best shape through the experimentation with. So what I suggest is that Jakarta Commons Math would benefit from having a parent project where there are applications to offer strong "working proofs of concept" of its usage.
Since Jakarta in and of itself has considerable focus on "Server Side Java" and specifically, tools that work well in its flagship Tomcat platform, there is concern as to if Jakarta is the right place for a project which may include adventures into Swing GUI's bridges with other programming languages and mathematical platforms, etc. I might suggest that there is really a very artificial and illusionary boundary between the concept of application and server. Is a Tomcat instance installed on my desktop a "server platform" or an "application platform". Really, all I know is its a damn good platform for doing just about anything to do with java on!
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 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".
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.
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.
Getting off my soapbox now (time for dinner),
Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
