New upstream version (4.0.12)

Now the new 4.0.12 release is out. An update for Karmic would be great.

An up-to-date package of the Java language bindings would be very nice. A note for the packager: 4.0.12 has some new dependencies.

I am working with Debian maintainer to update the package. We will hopefully have it before feature freeze.

So, Guillaume did a lovely 4.0.12 package in his PPA. Can you use that?
https://launchpad.net/~respawneral/+archive/ppa/+build/1131323

It'd be nice to link to an offical package rather than this, but his is up-to-date, so that's what we're promoting
http://java-gnome.sourceforge.net/4.0/get/ubuntu.php

AfC

@Andrew,

I started working on the package update in Debian even before what Guillaume did. Right now the packaging bits are sitting in pkg-java svn waiting for sponsorship.

I wouldn't mind uploading Guillaume's package if mine was not already ready. Also uploading his means I (or some other developer) have to review it. I hope next time I can collaborate with Guillaume. :-)

@Onkar, It would be my pleasure ;-)
My package may have some things badly done because I am not really a "packager guy". Anyway, I hope that my package can help you to update the official one.

This bug was fixed in the package java-gnome - 4.0.12-1

---------------
java-gnome (4.0.12-1) unstable; urgency=low

  [ Manu Mahajan ]
  * Update to latest upstream release 4.0.12 (LP: #380446)
  * Split the binary package into two separate packages for java and jni files

  [ Onkar Shinde ]
  * debian/control
    - Add various build dependencies as specified in configure file in upstream
      source.
    - Remove build dependency default-jdk-builddep. We do not build any -gcj
      package.
    - Add default-jre | java5-runtime as dependency since the target JVM
      version is 1.5.
  * debian/rules
    - Remove the hard coded version of jni .so file.

  [ Torsten Werner ]
  * Change Section: java.
  * Add get-orig-source target to debian/rules.
  * Minor fix in debian/copyright: do not refer to unversioned GPL file.

java-gnome (4.0.9-2) unstable; urgency=low

  [ Manu Mahajan ]
  * Merged changes from Ubuntu package(4.0.9-1) courtesy of Hannes Wallnoefer

java-gnome (4.0.9-1) unstable; urgency=low

  [ Hannes Wallnoefer ]
  * New upstream release 4.0.9
  * Remove Cairo export patch, bug has been fixed upstream
    (Gnome bug #528282)

 -- Onkar Shinde <email address hidden> Mon, 24 Aug 2009 13:05:50 +0100

> Split the binary package into two separate packages for java and jni files

Hm. That sounds strange, but I only see one .deb and that's right.

Just to be clear, though, to avoid potential future misunderstandings:

The Java (.jar) and C (.so) parts of java-gnome are 100% tightly coupled. They are not API / ABI compatible between different releases, and there is no public API on the JNI side. So seeing "separate binary packages" sounds dangerously like someone is wanting to create two independent binary products from one source tree, though I only see one .deb which seems correct.

++

The loading of native code by Java programs being frought with difficulty and a very common source of nightmare for developers and users. We went to significant (and quite innovative) lengths to engineer this problem out entirely.

> Remove the hard coded version of jni .so file.

I'm not sure what that meant. I suspect it just meant cleaning up previous packaging work.

When I looked, however, I found something called 01_change_jni_library_location.diff You do not need that patch at all. Instead, just use the confgure line:

./configure prefix=/usr jardir=/usr/share/java libdir=/usr/lib/jni jdk=/usr/lib/jvm/default-java

(based on reading http://launchpadlibrarian.net/30728086/buildlog_ubuntu-karmic-amd64.java-gnome_4.0.12-1_FULLYBUILT.txt.gz and https://launchpadlibrarian.net/30722782/java-gnome_4.0.12-1.diff.gz) where the libdir option gets you what you were trying to do with the patch. It is, however, *critical* that you use configure to tell the build system about where the .jar and .so are to end up, because that information is propegated elsewhere.

Incidentally, Debian, Gentoo and Fedora's requirements have been catered for since the beginning. If you do need something that usptream doesn't do, then upstream will change to accomodate it because it is important to us that the experience using a package and the experience building from source be the same. That's why libdir= and jardir= overrides are offered to packagers.

++

Oh, from the build log:

> # We don't install this one
> rm -f debian/tmp/usr/lib/libgtkjava-4.0.so

We don't create that file [not since, oh, mid java-gnome 4.0.7? March 2008 at the latest] so no need to remove it :)

++

I appreciate all the hard work of the people packaging java-gnome for Ubuntu and Debian. I've met Manu and Guillaume before, of course, but it'd be nice to get to know the others. You're welcome to join us on IRC or via mailing lists. Cheers.

AfC

> Hm. That sounds strange, but I only see one .deb and that's right.

Not sure where and when you looked. I see two packages for every arch on which the build is concluded.
https://edge.launchpad.net/ubuntu/karmic/+source/java-gnome
Perhaps you looked at it before the new binary packages for cleared from queue.

> Just to be clear, though, to avoid potential future misunderstandings:
> The Java (.jar) and C (.so) parts of java-gnome are 100% tightly coupled. They are not API / ABI compatible between different releases, and there is no public API on the JNI side. So seeing "separate binary packages" sounds dangerously like someone is wanting to create two independent binary products from one source tree, though I only see one .deb which seems correct.
> The loading of native code by Java programs being frought with difficulty and a very common source of nightmare for developers and users. We went to significant (and quite innovative) lengths to engineer this problem out entirely.

The libjava-gnome-java package depends on libjava-gnome-jni. So there is no chance of use installing the .jar file without .so file. The reason they got split is because it is usual practice. The .jar is architecture independent so it lives in a 'arch:all' package. The .so is dependent on architecture so it lives in a 'arch:any' package.
Also I had tried the simple hello world example (from java-gnome website) on Debian before asking the sponsorship. It ran without problem. If there are any more test suites you would like me to run, let me know.

>> Remove the hard coded version of jni .so file.
> I'm not sure what that meant. I suspect it just meant cleaning up previous packaging work.

Yes.

> When I looked, however, I found something called 01_change_jni_library_location.diff You do not need that patch at all. Instead, just use the confgure line:
> ./configure prefix=/usr jardir=/usr/share/java libdir=/usr/lib/jni jdk=/usr/lib/jvm/default-java
> (based on reading http://launchpadlibrarian.net/30728086/buildlog_ubuntu-karmic-amd64.java-gnome_4.0.12-1_FULLYBUILT.txt.gz and https://launchpadlibrarian.net/30722782/java-gnome_4.0.12-1.diff.gz) where the libdir option gets you what you were trying to do with the patch. It is, however, *critical* that you use configure to tell the build system about where the .jar and .so are to end up, because that information is propegated elsewhere.

I had not worked on that patch. I will take a look and drop it if necessary.

> Incidentally, Debian, Gentoo and Fedora's requirements have been catered for since the beginning. If you do need something that usptream doesn't do, then upstream will change to accomodate it because it is important to us that the experience using a package and the experience building from source be the same. > That's why libdir= and jardir= overrides are offered to packagers.

There is one thing you could change in the build process. The javadoc generation currently fails in build environment. The reason seems to be that the doc generation process tries to take screenshot by launching application (using something called Harmony). This is not possible in the build environment in Debian/Ubuntu. Please let me...

There is no guarantee that the .jar produced by our project is architecture independent. If it happens to be the case now then that is a coincidence and not a commitment.

I'll say it one more time: the .jar and the .so are completely coupled. There is NO point whatsoever in separating them.

You're the ones maintaining the packages. If you want to do the extra work, you go right ahead. I'm just warning you that based on experience packaging two eras of java-gnome on mutiple distros over the last 6 years, I think splitting it the way you're doing is stupid, because I've lived exactly the sorts of bugs you will be inflicting on your users as a result, and the pain that you will be inflicting on your upstream as they try to help you users. java-gnome 4.0 is the way it is in large measure because of our pain in dealing with these bugs during the 2.x era, and our engineering that pain out of existence. So you can imagine my less than profound enthusiasm to hear of a distro attempting to go back down that road. But, hey, that's software freedom for you.

> If there are any more test suites you would like me to run, let me know.

$ make test

> documentation

$ make doc

Generating the documentation requires an X server, as does the test suite. Feel free to use Xvfb. One of these days someone will finish the code for java-gnome to fire one up automatically, but we ran into some theming bugs last time we tried. Something to do with gnome-settings-daemon changing the way it behaves.

Anyway, as a workaround, if you do:

$ DISPLAY= make doc

you'll skip the screenshot part [that workaround is hard coded in at the moment], but your docs will look terrible. We're fully aware that this isn't optimal for build farms, but we're not optimizing for build farms. So, {shrug}.

++

Just FYI (and my fault too for starting it by commenting here), this is a discussion that we'd be better having on java-gnome-hackers or in #java-gnome [irc.gimp.net]. I'm rarely able to use sites like Launchpad.

But — and this is the important part — if you've picked up this package because you're [considering] *developing* with java-gnome, then that's what I care about. Packaging the library for your distro is necessary for us to package apps that depend on it, but the point is the apps. I hope you have fun.

All the best,

AfC

@Andrew,

I understand your concerns regarding the split of the package. Rest assured I will revert these change at the first sign of breakage caused by the change.
Meanwhile I will also try to go through the code and test suite to get better understanding of the code so that the changes made to the packages do not make them behave different from upstream distribution.

Thanks for the workaround for building doc. I will try that and will check how horrible the docs look. I will also check if I can take screenshots outside the build farm process and include them as patches (using uuencode/uudecode).

Let's close the discussion here. I prefer IRC over mailing list for quick discussions. But I will at least subscribe to the mailing list.

Haven't seen you online IRC, and I'm not sure if you're (yet) on our mailing lists (and I'm not sure if Launchpad tells you these things automatically now) so this once only: java-gnome 4.0.13 was released Thursday 27 August 2009.

[in time for your version "k" feature freeze, at least, that was the idea]

Just FYI. Over to you 'n all that :)

AfC

@Andrew,

Have been busy with office work lately. I will check the new release. It will require a feature freeze exception. I will try for that. :-)