Updating Jakarta Commons packages

[Barry Hawkins <barry@bytemason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Debian Java Community,
    Some of our Jakarta Commons packages need updating, and in the
course of discussing this on IRC at #debian-java, some issues have come
up.  To illustrate these issues, I will use the example of our packaging
of Jakarta Commons Collections, a library in fairly wide use within Java
applications.  I have two general recommendations, then a specific
proposal for Commons Collections that actually involves me doing work. 8^)

General Recommendations
1. Use version numbers almost always.  Our current policy[0] shows this
as optional, but I believe it should be more the standard we follow by
default.  Java libraries, in this case Jakarta Commons libraries, are
almost always vulnerable to incompatibilities between major versions.
Seasoned Ant users and Maven as a whole[1] (thanks Trygve Laugstøl) have
chosen versioned .jar files to address this.

2. Do not prefix the source package with "lib".  Libraries, at least
most of the ones worth packaging, almost always ship their docs in the
tarballs.  Having a source package whose name matches the binary package
for the library itself loosely implies that is all it's for.  Since some
libraries also ship with examples and testing frameworks, this can
become even more confusing, as can be seen in the one bug for
libcommons-collections3-java[3].

Jakarta Commons as an Example
    Below I have outlined the current source packages and their
corresponding binary packages, followed by a proposed reorganization for
Jakarta Commons Collections 2.1.1 and 3.1.  Please comment on these
suggested approaches.  I would like to implement this soon.

Currently Structuring:
Source Package: commons-collections
Binary Packages:
libcommons-collections-java stable (libs): A set of abstract data type
interfaces and implementations [contrib]
      1.0-1: all
libcommons-collections-java-doc stable (doc): Documentation for
libcommons-collections-java [contrib]
      1.0-1: all

Source Package: libcommons-collections-java
Binary Packages:
libcommons-collections-java testing/unstable (libs): A set of abstract
data type interfaces and implementations
      2.1.1-3: all

Source Package: libcommons-collections3-java
Binary Packages:
libcommons-collections3-java testing/unstable (libs): A set of abstract
data type interfaces and implementations
      3.1-2: all

Proposed Alternative Structuring:
Source Package: commons-collections
Binary Packages:
libcommons-collections-java stable (libs): A set of abstract data type
interfaces and implementations [contrib]
      1.0-1: all
libcommons-collections-java-doc stable (doc): Documentation for
libcommons-collections-java [contrib]
      1.0-1: all

Source Package: commons-collections2
Binary Packages:
libcommons-collections2-java testing/unstable (libs): A set of abstract
data type interfaces and implementations
      2.1.1-3: all
libcommons-collections2-java-doc stable (doc): Documentation for
libcommons-collections2-java [contrib]
      2.1.1-3: all

Source Package: commons-collections3
Binary Packages:
libcommons-collections3-java testing/unstable (libs): A set of abstract
data type interfaces and implementations
      3.1-3: all
libcommons-collections3-java-doc stable (doc): Documentation for
libcommons-collections3-java [contrib]
      3.1-3: all


[0] - file:///usr/share/doc/java-common/debian-java-policy/x105.html
[1] -
http://blogs.codehaus.org/projects/maven/archives/001052_why_maven_uses_jar_names_with_versions.html
[2] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=268223

Regards,
- --
Barry Hawkins
All Things Computed
site: www.alltc.com
weblog: www.yepthatsme.com

Registered Linux User #368650
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCapW9HuKcDICy0QoRAkgSAKCiBFrPBsFwZY1ajsVvelLP0b6ykACeJlss
lY6SuQlCLCzVxJl01naorCs=
=d3/l
-----END PGP SIGNATURE-----