=======================================================================
April 8, 2001: Jakarta-commons Summary digest
Summarizing list traffic from Apr 1 through Apr 7.
=======================================================================
Topics general to Jakarta-commons:
[Voting procedure]
Discussion:
- According to the charter, 75% approval required (8 committers).
- Therefore no projects [had been] officially approved
- Are there issues with 'scaling' to large # of committers?
Should the rules be revised?
- Could lower the % needed
- Could use 75% of those that voted
- Could set a threshold number of +1 votes
[Commons website]
Progress:
- Commons page posted with some structural outlining. Open for
suggestions and enhancements.
- Some terminology more clearly defined
Discussion:
- Debate on whether to use Anakia, stylebook, XSLT, or DocBook
- XSLT and DocBook are more standard, but Anakia is jakarta-based.
- Directories beneath the main project page can be implemented
in any fashion, as long as they strive for a consistent look.
- Commons needs a logo [some submissions discussed]
Will the generated html be stored in CVS?
- Geir initially wanted it so, but decided against it
[Operating guidelines]
RFC to collect content for an operating guidelines doc
[Sub-projects]
What is the project's life cycle? (proposed)
- Developer has an idea for new project
- Developer solicits feedback from the list
- With approval, a committer can add directly to main CVS
- With approval, a contributer adds to the sandbox
- Once mature, a vote determines whether an authorized release
is warranted
How should test classes be organized?
- Some prefer them adjacent to target classes for close
interaction and to encourage more testing
- Others prefer the cleanliness of having a separate directory
How should bugzilla handle the subprojects?
- Currently, "commons" is treated as a whole project in bugzilla.
Will each sub project have its own versioning?
How should docs be written?
- Generate from XML or other source
- Should be standalone so each package lives on its own
[Automated project builds]
(Much, much, debate...Here's what I got through the fog.)
- Developer nightly builds and end user builds are 2 entirely
different needs with different support structures
- Gump should be used to handle automated nightly cross builds
- The nightly builds for the jakarta-commons code base should
"play nice" with everything else, especially if other Jakarta
projects depend on it.
- For end users, the jakarta-libs needed to perform a complete
build could be included in the downloaded tree
- Libs included in an end-user build would be Ant, Xerces, and
Velocity
- End-users should also be able to download individual JARs for
released versions of the libs, rather than the entire commons
collection
- There may be a middle ground where developers want a snapshot
and may desire to have the dependencies bundled with the source.
- Could use a standard set of targets: use/help, clean, build, doc,
test, dist, and commit. Then each sub-project could reference a
master buildfile that handles most projects.
- Could also include real-clean to clean the target directory(s)
[Use of the sandbox]
- An "approved" subproject should probably not have a dependency
on a new module that is in the sandbox
[Weekly digest]
- Should a periodic email be sent to jakarta-general?
- The PMC is working out some ideas for jakarta communication
that is community-wide
[Managed JAR repository]
- A stable server for people to grab from in Ant scripts
=======================================================================
New proposals:
[NONE]
=======================================================================
New submissions to the sandbox (without proposal):
[NONE]
=======================================================================
Progress and other threads
[Cactus]
Progress:
- Approved as a commons sub-project
- Moved from sandbox into main tree
Discussion:
- Naming the downloadable files: one big tgz and/or separate JARs?
[JOCL]
Progress:
- Proposal dropped for now while JOCL/Digester merge considered
Discussion:
- JOCL + Digester sounds feasible
- Overlap with Merlin/JDK-1.4?
- Overlap with SOAP?
- Does not require intermediary classes, just XML description and
the given target class
- Allow arbitrary method calls (not just constructors)?
- Support map of object references?
- Maybe fold back into DBCP while the merge with Digester churns
- Digester is not designed for using constructors with arguments,
but JOCL is.
- Unclear whether Digester requires custom coding for each class
- Digester has a more readable XML format
[Collections]
Progress:
- Proposal re-submitted
- Source placed in the sandbox
[Object Pooling]
Progress:
- Costin intends to add the pool package from Tomcat3 to the
sandbox. Perhaps they could be merged?
- Source placed in the sandbox
Discussion:
- org.apache.tomcat.util.collections.SimplePool and
org.apache.commons.pool.ObjectPool are functionally similar.
- Perhaps cleaner separation between pool tasks and
instance-grabbing tasks would help? Perhaps a listener?
- Maybe a bean/listener approach would be better than an
interface/API approach?
- The PoolableObjectFactory may suffice for the listener/API
approaches. Listeners could (should?) be added here.
- Perhaps pool implementations would be too different to fall
under a common pool API. Perhaps also, those pools always have
similar methods, so an interface API would help to consolidate
those differences.
- Debates over best way to grab instances from the factory
[DBCP]
Progress:
- Proposal re-submitted
- JOCL folded inside
- Source placed in the sandbox
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
