I propose that the requirement to add the upstream version number to
the jar installation and the symlink from the non-versioned name be
dropped.  Discussion on debian-java@l.d.o showed that no one really
knows what this is supposed to be for, no one wanted to defend it, and
it doesn't seem to have technical value.

In particular, replace this text:

    Their classes must be in jar archive(s) in the directory /usr/share/java,
    with the name packagename[-extraname]-fullversion.jar. The extraname is
    optional and used internally within the package to separate the different
    jars provided by the package. The fullversion is the version of that jar
    file. In some cases that is not the same as the package version.

    Some package must also provide a symbolic link from packagename-extraname.jar
    to the most compatible version of the available packagename-extraname-version.jar
    files.

by this text:

    Their classes must be in jar archive(s) in the directory /usr/share/java,
    with the name packagename[-extraname].jar. The extraname is
    optional and used internally within the package to separate the different
    jars provided by the package.

(Perhaps some advice on how to deal with incompatible API changes would
be useful to have in there, but the current mechanism doesn't help with
that anyway, so let's kill it.)

On Tue, Apr 18, 2006 at 01:23:56AM +0200, Peter Eisentraut wrote:
[...]
[...]
Peter,
    I replied to that posting[0], and I don't think the discussion yielded
a lack of support for using version numbers in .jar file names.  Since
nobody responded to the issues mentioned there, I cannot see why we should
implement this request.

What is the significant gain you propose by not having version numbers?
The version numbers are a lightweight (though imperfect) means of dealing
with the inevitable situation of incompatibilities between versions of an
API.  For example, when a maintainer is packaging a Java API that depends
on the Jakarta Commons HTTPClient version 3.0, they at least can see that
the symlink commons-httpclient.jar points to commons-httpclient-2.0.2.jar
and have some insight as to why their package isn't behaving properly.

[0] - http://lists.debian.org/debian-java/2006/03/msg00078.html

On Tue, Apr 18, 2006 at 01:23:56AM +0200, Peter Eisentraut wrote:
[...]
[...]
Peter,
    I replied to that posting[0], and I don't think the discussion yielded
a lack of support for using version numbers in .jar file names.  Since
nobody responded to the issues mentioned there, I cannot see why we should
implement this request.

What is the significant gain you propose by not having version numbers?
The version numbers are a lightweight (though imperfect) means of dealing
with the inevitable situation of incompatibilities between versions of an
API.  For example, when a maintainer is packaging a Java API that depends
on the Jakarta Commons HTTPClient version 3.0, they at least can see that
the symlink commons-httpclient.jar points to commons-httpclient-2.0.2.jar
and have some insight as to why their package isn't behaving properly.

[0] - http://lists.debian.org/debian-java/2006/03/msg00078.html

Am Dienstag, 18. April 2006 22:23 schrieb Barry Hawkins:

The points you listed are:

1.) Java(TM) libraries have a notorious tendency (not unlike other languages)
    to not preserve backward compatibility between significant revisions.
    [...]

This may be true (although I don't believe it) but the current system does
nothing in the way of solving it.

2.) A given library may have multiple versions within the Debian repository at
    a given time.

That means that *if* a package has multiple versions in the archive, then a
versioning mechanism has to be used.  But many packages don't need this.

Simplification.

That's the point.  They don't actually deal with it.  At least not with a lot
more infrastructure that I don't see defined anywhere.  For instance, if this
is supposed to be supported, then all Jar references in other packages would
really need to be versioned.  And there would need to be some way of having
major/minor version numbers, so an upgrade from version 2 to 3 would create
an incompatibility but an upgrade from 2.0.1 to 2.0.2 would perhaps not.  And
the version is currently required to be the version number of the package,
which says nothing about compatibility.  C library sonames are distinct from
package versions.

If there is a feeling that managing C library-like soname upgrades is useful
for Java libraries, then I would certainly support that.  But the current
system is a solution in search of a problem.

That sort of argument would call for symlinking everything to versioned files
(think /bin/sed-4.1.4).  This is not a Java-specific problem.  If you want to
know the version of a file, use dpkg.

[...]
If you don't believe Java libraries have issues with not regularly supporting
backward compatibility, then I would wonder how much enterprise development
experience you have with Java libraries ;-).

I think you make some excellent points here.  In your initial message, I thought
you were advocating the dropping of version numbers and not trying to do anything
else, which I would consider reckless and unwise.  Adopting a solution for languages
that have a longer history in Debian with some proven solutions seems like a wise
approach to me.  So, Debian Java Maintainers, let's hear from you on this!  We
have to work this topic out if we are going to get a decent Java policy ready at
any point in the near future.

Regards,

Barry Hawkins wrote:
[...]

How about using the `Specification-Version:' in the Jar Manifest[0] ? As
described in [1], it would be possible to define within each Jar file
wich specification version is provided by a Jar file. I think this
addresses the problem discussed here.

But that would be a burden on packagers, since AFAIK not many Java
developpers use this field...

Thomas

[0]
http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.html#wp91706
[1]
http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioningTOC.html

[...]
Thomas,
    Thanks for weighing in!  My experience would concur with your observation;
few of the F/OSS Java projects I have worked with do a consistent job of using
the manifest correctly.