The ultimate goal of any "Commons" is to develop a shared codebase of components that are not large enough to be maintained on their own, and reduce "replication of functionality" in separate projects. This is not only "integral" to a healthy developing codebase at Apache, it is necessary for maturation of the Apache codebase from a "bunch of widgets" to a "well oiled machine".
I personally think that the idea of "Commons" should become more "Virtual" and "Evolutionary" in nature. That maybe there should be less "restrictions" on its location and development. Forget the issues of being programming language "agnostic" or programming language "specific" and consider the value that would be "gained" by sharing such communities.
For instance, if theres ever the case that "xml commons" and "jakarta commons" could become a shared community, it would produce the following benefits:
1.) A reduction in "duplication" of content between the xml and jakarta communities.
2.) A shared usage of the codebases would produce tools that are clearly defined and work well together.
3.) An optimization of programmer effort, time spent by programmers separately maintaining duplicate codesbases is reduced.
With this in mind, the idea of an "Apache Commons" becomes logical. BUT... not as a place that all "Commons" get migrated to and housed at under one PMC, but more as a "Virtual Collection" of all the "Commons" projects at Apache. Literally, just being a "Portal" to the individual Commons sites. In fact, instead of migrating all "Common" code to "One place", maybe it would be more logical to allow it to be maintained under the foundry or TLP project that produced it and simple provide such a "Symlinking" of the codebase into the Commons such that other projects are aware of its existence and availability.
Apache Commons:
--> Jakarta Commons
--> subprojects --> XML Commons
--> subprojects --> TLP Project
--> TLP projects shared common codebase.This way shared code is managed and packaged by its creators, but advertised for reusage by the Commons.
Eventually alot of valuable lessons learned by the various commons projects would give rise to a standard project layout and packaging requirement for a codebase which is to be maintained as a Commons Codebase. In essence, this is not much different conceptually than the idea of COM and dynamic linking. The goal being, not to make every project house its common codebase in one specific location (which is totally unscalable) but to define logical rules for the "structure", "building", "packaging" of a Common Component such that it can be reused by other tools. In reality, isn't this what is being promoted through Maven, both with the idea of a Maven Repository and a Standard project layout and building strategy?
With this in mind I say the following:
1. "Common Codebases" can (and should) be maintained anywhere in Apache, but be advertised in a registered location (like Apache Commons) and yet be maintained by their individual developers in their location of origin.
2. "Common Codebases" should be structured, built and packaged based on a "clearly defined specification" such that they can be published in repositories and easily rebuild and repackaged.
-Mark Diggory
-- 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]
