1.) Argument exists concerning the dependency requirements of Commons Math. To in fact be "modular" and "easily integrated" some discrepancy arises concerning interdependency with other commons components. The main question is; Are all these dependencies really required?
a.) logging: It sounds like a good idea to make logging a runtime/compile time dependency on only the test cases and not the main library. Is this logical to everyone? I really like the idea and as logging is really used "minimally" in only about 4 classes, this should be easy to work around.
b.) Some discussion arises concerning some of the "higher level" interfaces and their dependencies on commons such as Discovery. We should review and grade if this Discovery pattern will really of "true" value in the places we've applied it (As opposed to just providing simple method of instantiation on these object directly...)
c.) j2sdk1.3.1 vs. j2sdk1.4.1: we are a project in a group dedicated to providing tools that can operate in Java Servlet/EBJ environments. Many vendors are still operating on 1.3.1. We have concerns as to our stuff working there. Thus we need to make sure we use only mechanisms supported on 1.3.1 for the time being (and then operate on a longer timescale to determine how facilitate usage of 1.4.1 in the future). I think currently the big area is "Exception handling capabilities" and our primary solution was to use "o.a.l.e.NestedException.
2.) Server vs Application schools, I tend to think this is a "Red Herring", this arises primarily by some great comments Eric made
Eric Pugh wrote:This backlash against multiple commons jars is happening in a lot of places. However, I think it is a bit shortsighted. If you are in a non server environment, I understand the problem, but in a server environment with lots of harddrive space, I don't. Additionally, since in a server app you are likely to need all thoses dependencies any way. I think almost every app I work on has commons-lang, commons-loggin, and commons-collections included. And then depending on what else, commons-discovery and commons-beanutils show up all the time!
a.) Even in a non-server environment, space isn't an issue, I think the real issue your seeing here is usage of "arcane" methods of setting up classpaths being approached by users of java programs as applications. All too often you come across the use of external scripting languages to manage execution of a java application. In the commons we have several efforts to alleviate this matter (CLI, Daemon, Hivemind). Outside of commons theres Classworlds, Ant etc that provide solid means of building up classpathing more dynamically. There are smarter ways to buildup your classpath and initial environment than a batch script. In which case whether a class is in /lib/a.jar or /lib/b.jar become less of an issue.
b.) The places where space becomes an issue are things like Applets. (Yikes). And really when it boils down to it, There are enough solid tools out there for optimizing applets, you should optimize the hell out of whatever your building to produce the lightest applet you possibly can at "development time", this is very independent of the actually packaging of the dependencies at development time. I don't think it something that the math project should limit ourselves by striving to provide.
I think thats about it for now.
Cheers,
-- 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]
