text: PROPOSAL:
  The major version number of a component, where it is greater than 1,
  shall be included in the package name.
  EXAMPLE:
  org.apache.commons.pool - version 1.x line
  org.apache.commons.pool2 - version 2.x line
  RATIONALE:
  Java has no mechanism for handling different versions of the same
  library where those versions clash. This leads to a situation known as
  'jar hell'.
  Consider application A dependent on frameworks M and N, both of which
  depend on a commons component X.
  A
  |
  -----
  | |
  M N
  | |
  -----
  |
  X
  Now consider what happens if framework M upgrades to a later version of
  X, but N does not. The standard approach is to drop in X2 and hope that
  N still runs.
  A
  |
  -----
  | |
  M N
  | |
  -----
  |
  X2
  However N may not run with X2 if the changes from X to X2 are major and
  incompatible (which should be signalled via a major version change).
  Given this situation, the application now has no simple options. They can:
  a) give up and not upgrade framework M
  b) petition framework N to upgrade
  c) dive into the open source and upgrade N themselves
  d) use two classloaders
  e) use fancy bytecode weaving tricks to merge the versions
  f) use jar embedding tools to alter N
  I would argue that the majority of developers would choose option (a)
  and give up. This is because while options b-f are possible, they are
  not what the average *user* wants to spend their time doing.
  Of course, all of this presents a very simple example. Most open source
  stacks are much deeper than this and thus the potential for jar hell is
  much higher.
  The proposed solution is to rename the package of each commons component
  at each major version change. This binds all the callers of the commons
  component to a different package namespace, and thus no clashes, or jar
  hell will ensue - except by human error.
  Why now? Because this is the time that the majority of components are
  starting to consider new incompatible versions, often related to JDK1.5.
  DOWNSIDES:
  - The client application has to change their package names when
  upgrading to a later major version of the commons component.
  - The client may get two versions of the same class in their IDE
  autocomplete (most IDEs allow this to be filtered)..
  Stephen
  ---------------------------------------------------------------------
  To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
  For additional commands, e-mail: commons-dev-help@jakarta.apache.org