At 07:41 22/2/01 -0500, Ted Husted wrote:
>+ The primary unit of reuse and release is the package.
>
>+ The package library is not a framework but a repository of codebases
>designed to be shared.
>
>+ Each package must have a clearly defined purpose, scope, and API -- Do
>one thing well, and keep your contracts.
>
>+ Each library package is treated as a product in its own right.
>
>- - Each package has its own status file, release schedule, version
>number, QA tests, documentation, mailing list, and bug category.
egads ! ;) maybe not a separate mailing list ;) A general list may help
build a community. If it becomes crowded we can always split it up later.
Seeing discussion on components may prompt others to use that component.
>- - Each package must clearly specify any external dependencies,
>including any other library packages, and the earliest JDK version
>required.
>
>- - - External dependencies on optional and third-party codebases should
>be minimized.
>
>+ Each package maintains a list of its active committers in its status
>file.
>
>+ The packages should use a standard scheme for versioning, QA tests,
>and directory layouts, and a common format for documentation and Ant
>build files.
+10000000000000 ;)
>+ The packages should fit within a unified package hierarchy.
>
>+ In general, packages should define an abstract interface, and provide
>one or more implementations of that interface.
Not a requirement as such. A package should do one thing well. If there can
be multiple strategies for doing it then have interface-implementation
difference. However most components don't need to have multiple
implementations.
>+ The packages should have boring functional names. Implementations may
>choose more "exciting" designations.
>
>+ Packages are encouraged to either use JavaBeans as core objects, a
>JavaBean-style API, or to provide an optional JavaBean wrapper.
>
>+ External configuration files are discouraged, but if required, XML
>format files are preferred for configuration options.
and read in by one of the standard XML config systems (ie
digester/configuration or tomcat 3.xs one - whatever that is ;])
>+ The package library subproject shall be proposed as a Jakarta
>subproject.
>
>+ Each package will be hosted on its own page on the subproject Web
>site, and will also be indexed in a master catalog.
>
>+ The subproject catalog will also provide a distribution mechanism.
>
>+ The subproject will also host top-level "general" and "announcement"
>mailing lists.
>
>+ The subproject will also provide a single JAR of all stable package
>releases. It may also provide a second JAR with a subset of only JDK 1.1
>compatible releases. A gump of nightly builds will also be provided.
>
>+ Committers join the library subproject in the same way they are
>entered to any Jakarta subproject. Being a committer in another Jakarta
>subproject is not a prerequisite, nor does it provide free entry to the
>library subproject.
unless they are moving code from the other project and are willing to act
as caregiver and guardian ;)
>+ Each committer has karma for all the library packages, but is expected
>to add their name to a package's status file before their first commit
>to that package.
>
>+ The library committers shall elect a committee of three committers to
>provide general oversight, in the style of the Jakarta PMC.
If it's needed. Until we can an army of developers I would suggest that it
is just overhead. When we hit some critical mass (say 15-20 developers)
then this would be something to consider then.
>+ New packages may be proposed to the library general list, and voted on
>by all committers. To be accepted, a package proposal must receive a
>positive 3/4's vote of the library committers. Packages proposed are
>expected to be used by one or more ASF products.
>
Other than points above +1
>(2)
>
>NEW BUSINESS
>
>The first packages on the library agenda will be:
>
>JDBC connection pool
+0
Nice idea but I don't know enough to help ;) I could help with formalizing
the other boring process stuff and setting up build docs etc though...
>Testing Framework
>
>Work on these packages will coincide with work on the library subproject
>infrastructure.
>
>Additional codebases to consider for the Testing Framework include
>
>http://sourceforge.net/projects/j2eeunit - Vincent Massol
Theres also HttpUnit which would be very useful at Apache and it's "owner"
was amicable to donation last time I mentioned it ;) However we should make
sure it is adopted by projects inside Apache before we try to adopt such
projects.
>http://sourceforge.net/projects/arrowhead/ - Kevin Burton
It is dual licensed and GPLed so a no go unfortunately. It is however based
on testlet from avalon CVS under jakarta-avalon-testlet.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
