Re: [Fwd: Re: [architecture] Re: JPackages and ObjectWeb]

[Jan Schulz <default@katzien.de>]

Hallo David,

* David Walluck wrote:
>>So if 1.5 is API compatible to 1.4, the the jar should still be
>>name-1.4.jar (or at least a symlink :) But if 1.5.3 breaks something,
>>it should get name-1.5.3.jar.
>But libraries have the concept of software version, and then totally 
>apart from this is the library version used by, for example, libtool, 
>and meant to distinguish API incompatiblities.
>I am not sure I'd want to mix the two. So in Java 1.5.3 is going to 
>refer to the software version and not the API compatibility level, so I 
>still think the jar should always be named with the full version. You're 
>not going to get any libtool type versioning going with such a simple 
>structure. You could attempt to make symlinks to every comptable version 
>from 1.5.0 up to 1.5.3, but that just gets really messy.

Hm, I would like to introduce that. Currently it is not possible to
support different API versions (API defined libtool wise) on a debian
system (AFAIK Jpackage also only support 'old' and the current
version). libswt currently is designed to do, but breaks debian java
policy. The current setup is like this:

libswt2.1-[motif|gtk2]-java provides libswt2.1-java
libswt2.1-java guarantees the there is a
/usr/share/java-config/libswt2.1-java file, which has a line 
|JARS="/usr/share/java/swt2.1-motif.jar"
or 
|JARS="/usr/share/java/swt2.1-gtk2.jar:/usr/share/java/swt2.1-gtk2-pi.jar"

So when I have a app, which wants to use swt, it can use this line to
figure out the classpath entry (that's basicly what findjava is for, in
my proposal). If swt3.0 is out, I will add similar entries and if it
breaks API compatibility to 2.1, I will have no problem, because all
jars are versioned and can so be installed next to a different version.

So IMO, versioned package name should go with versioned jars. Even if
they are used through a script. The only garantee, which should be
made is, that one package name contains jars with the same name as any
former version of that (versioned!) package. This way you can symlink to
it without a problem. And if API breaks, you have a new package and so
everything stays fine.

In some cases (when using a script to help over the issue), you
could even split the jars, as long as the API stays backward
compatible. eclipse.org has a nice article about designing and
evolving stable API.

>I understand from a Debian perspective, you want to name your package 
>libfoo1.5-1.5.3 and be done with it, but we have no guarantee of the API 
>compatibility level.

You never have until a) upstream documents it, or b) it breaks.

In first case, you can do the change beforehand, in the second case,
you need to do two uplaods, one with a source package of the older
source package with a newer version number (epoch... :( ), so that the
old API gets installed again unbreaking the system and uploading the
new source with a new package name (and different source name).

Thats at least the way I would handle it on debian. And the second
case should be catched by some testing...

In the both cases you would end with two source packages (named
diffrently) and two packages, ones the old version and the new
version.

>In Java, it *always* seems to be the case that it 
>changes, even in *micro* releases, which is to say, that only 
>libfoo1.5.3-1.5.3 may be sufficient for some software.

Package, which need that are probably not fit to be called library...
That's another thing, what libraries should be: have stable API. In
this case it would be better to link statically -> include the jar.

[re-finding old rules for java]
>In short, just because you are I might be used to all of these things 
>being second nature, they obviously aren't in the Java world, or we 
>would even be here having this discussion, would we? :)

So it's good that we have it :)

Jan
-- 
Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."