commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Jakarta-commons Wiki] Update of "id/1.0ReleasePlan" by JörgSchaible
Date Mon, 16 Jan 2006 20:37:14 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification.

The following page has been changed by JörgSchaible:

The comment on the change is:
Summary of the release plan for commons-id 1.0 as already discussed on the list.

New page:
= Release Plan For Commons Id 1.0 =

== Background ==

Commons-Id exists now for several years in TheSandbox of Jakarta Commons and has now attracted
some developers to build a community, that can maintain the component and it has substantial
implementations for various useful identifier generators. Since 1.0 is the first official
release, some changes can still be rather drastic to ensure the longevity of the released

== Status ==

Planning stage - straw man.


= Pre Release Tasks =

== Coding ==

 * Review UUID implementation and verify the spec compliance [[
RFC 4122]]
  * Verify spec compliance
  * Check against JDK 1.5 functionality
  * Introduce a UUIDIdentifierGenerator interface extending StringIdentifierGenerator with
extended functionality to get the identifier directly as UUID or additionally as byte array.
  * Review the internal plugin mechanism
  * Fix persistent store of State (ensure usability in system class path and application class
 * Drop IdentifierGeneratorFactory and IdentifierUtils
  This elements used static versions of each available IdentifierGenrator implementation and
parametrization to provide a convenient way to access the generators available in commons-id.
With the addition of new generator implementations the convenience for users vanish in combination
with the maintainability.
 * Refactor PrefixXXXGeneratorIdentifier implementations
  It might be useful for all String-based generators to decorate the created identifier. The
3 current prefix implementations should be replaced by a generic decorator or transformator
 * Introduce a Wrappable interface for serial generators that may wrap
  Most implementations of serial identifier generators currently support a flag ''wrap'',
that enables the generator to start over with the sequence of identifiers if the generation
maximum is reached. The interface should be introduced to unify the access to this flag.
 * Hide copied code from commons-codec
  To prevent a dependency on commons-codec two utility classes (DigestUtils and Hex) were
copied along with two exceptions (EncoderException and DecoderException) into commons-id.
These classes are now located very prominent in the top level package and are currently
part of the official API. Best solution would be to have them package scope or put them at
least into a package
 * Make GeneratorIdentifier implementations serializable
  Most of the generator implementations could be made serializable without any problem. Serialization
should be ensured by appropriate unit tests though. The serializable implementation should
also support a serialVersionUID. We might either use just 1L or the date we added this UID
in form of YYYYMMDDL. Setup test code to ensure binary compatibility with future versions.
 * Clean-up exception handling
  Some methods have currently signatures for exceptions they do not throw. Some code throws
a simple RuntimeException instead of introducing a derived exception for the commons-id components.
A lot of internally runtime exceptions are not mentioned in the javadoc.
 * Improve test path coverage and fix remaining style issues
 * Unify initialization of unit tests
  A lot of unit tests use a suite method, have a constructor to parametrise the name and have
a main method. All of this is normally not necessary in modern IDEs. In Eclipse this is even
worse, since you cannot click on the run tests to switch to the test's source. '''Done.'''
=== Documentation ===

 * Rewrite the introduction to commons-id, since it currently references the convenient classes,
that will be dropped
 * Add existing identifier generators to overview table
 * Update UUID documentation after changes from the review
 * Add examples
 * Add FAQ

=== Javadoc ===

 * Drop duplicated javadoc
  If a method is overwritten in a derived class, it should either describe, what it does different
or don't add any javadoc, so that the documentation is automatically copied by the javadoc
tool. In case of repeated description for a single parameter, return value or thrown exception
an {@inherit} element should be used.
=== Quality ===
=== Check Compatibility ===

 * Ensure JDK 1.3 compatibility

=== Build ===

 * Use Cobertura for coverage report

== RC(s) ==

 * Once tasks above a completed, create release branch and roll a full RC
 * Repeat for n=2, 3, ... until all are happy (see below :-)

== Release Notes ==

== Release Vote(s) ==

If no objections are raised on problems reported with an RC after two days, a VOTE thread
will be kicked off.  If problems are reported during the vote, these will be fixed and a new
RC will be made available and a new VOTE initiated.  This process will iterate until we have
had a successful VOTE thread extend for 72 hours.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message