FeatureFreeze exception request for sun-javadb

[Lars Heill]

*** Proposed change

Add new sun-javadb package - see http://revu.tauware.de/details.py?package=sun-javadb.
Since the package is new and there are no dependencies on it, there is no impact to the distribution other than having this new package available.

*** Rationale

The main binary delivered by sun-javadb is derby.jar which currently exists in Ubuntu in the packages sun-java6-javadb and sunwderby (with sunappserver, aka GlassFish v1). Also, another new package is currently proposed (GlassFish v2), including derby.jar. These are version 10.2.2 of derby.jar, and are getting old. sun-javadb would bring version 10.3.

The proposed sun-javadb is meant to replace the current sun-java6-javadb to reflect the the other distributions of Sun's JDK 6: Java DB is not part of the JDK, but is copackaged - this would be similar to other platforms/distros where you get separate Java DB packages with your JDK6 download (except
for the file based "developer tarballs"). The current version 10.2 of Java DB in sun-java6-javadb is outdated and behind the current Sun JDK package which is 10.3 now.

The ultimate goal is to have the JDK as the primary delivery vehicle for Java DB ("Derby") while Java DB still is a separate product used in/by other products/consolidations like GlassFish and NetBeans. These should ideally not deliver their own Java DB/Derby binaries, but rely on those made available by the Java DB package.

Until we get there, those other products/consolidations may need to bundle their own copy/version of derby.jar (and some other files) since they have based their functionality and testing on this. GFv2 is
already out there and changing derby.jar mid-flight is not desireable. For GFv3, however, we hope to have a proper dependency on the Java DB package in place across the board (except of course any file based distributions, but that is outside the scope of this).

So, we request the addition of the sun-javadb package

1) to prepare for the future single delivery of derby.jar & co through sun-javadb and other packages' dependencies on it; and
2) bring the version of Java DB/Derby up in synch with the rest of the world.

Since this would be the first integration of the package, there are no relevant code diffs and tests against older versions. The current package on REVU is lintian free and installs and uninstalls cleanly.

[Lars Heill (heill)]

This is a FYI.

[Lars Heill (heill)]

Not but on product/project, FYI only.

[Emmet Hikory (persia)]

Just as a note for review, this package would be unused by either v1 or v2 of GlassFish (as it is apparently not compatible with the derby in GlassFish v2). It would also be unused by NetBeans: hardy has the latest upstream NetBeans (6.0.1). It may be useful in the future for other things.

[Scott Kitterman (kitterman)]

Since it's a New package it doesn't impact archive admin workload. I'm not a Java expert, but none of that sounded like anything other than nice to have. Is there a reason we really need this for Hardy?

[StefanPotyra (sistpoty)]

Hm... 1) doesn't seem to be a reason to include it in hardy, as no packages for hardy would get adapted, right?
I cannot say, I have enough knowledge about java libraries to rate 2. Hence I'm subscribing Matthias. Can you give a thumbs up/thumbs down on this?

Cheers,
     Stefan.

[Lars Heill (heill)]

I would like to point out that Java DB is not just a library for use under the covers of other applications. Java DB is a full-featured database in its own right, I would definitely say the leading Java database out there - from the introductory paragraph:

"Java DB is Sun's supported distribution of the open source Apache Derby 100% Java technology database. It is fully transactional, secure, easy-to-use, standards-based — SQL, JDBC API, and Java EE — yet small, only 2MB. The Apache Derby project has a strong and growing community that includes developers from large companies such as Sun Microsystems and IBM as well as individual contributors."

Customers and users deploy on the Java DB database in stand-alone, embedded, local or in client-server mode. And even on small devices (phoneME, e.g) or for browser off-line plug-in applications etc etc etc. A lot of background information is available on http://developers.sun.com/javadb/. There you can also purchase 24x7 support.

It is the default database for Sun's Application Server (open sourced as GlassFish), Portal Server and Service Registry, and is supported by NetBeans, Java Studio Enterprise and co-distributed with Sun's JDK 6.

It would not be unused by NetBeans, merely not yet immediately picked up in the required debian install path /usr/share/javadb yet: there is a NB change request to automate this in the coming NB 6.1M2: http://www.netbeans.org/issues/show_bug.cgi?id=126765. Until then, the NB user can point NB to /usr/share/javadb if he so pleases.

I would absolutely not dismiss Java DB as merely a "nice-to-have"! Perhaps my initial rationale did not step back far enough to bring in the full picture. ;)

Should you need a database, and in particular a small yet full featured one for your Java application/environment, this is definitely it!

(and of course it should obsolete and replace the existing sun-java6-javadb package, so no extra load or footprint)

[Lars Heill (heill)]

Stefan, I hope my above expansion is a better basis for you to assess this: Java DB is not just a library to be included by other products, it is a full featured database product in its own right :)

[Scott Kitterman (kitterman)]

It helps me understand what it is and why it would be nice to have. You
reference to future releases worry me. Are there more reqests coming if we
take this?

[Lars Heill (heill)]

Sorry if the future came across in a worrying way :)
No, rather the opposite: the target is to consolidate the use of Java DB on just sun-javadb, which - in the hopefully near future - will make it unnecessary for others to bundle their own copies. For Java DB, this is the only request you will receive. (there will of course be new upload request for new upstream releases and such of the same package)

[StefanPotyra (sistpoty)]

Proxying comment:

<doko> sistpoty|work: I don't mind, but the license for sun-javaN forbids replacement of some bits with external replacement bits, so we cannot depend on it. besides that, the package as found on revu has missing b-d's, ignores naming standards for java libraires, and maybe more ...

[StefanPotyra (sistpoty)]

Given that the package obviously still needs some work, I'm inclined to reject this exception request. Eventually, if the package should come into good shape, maybe until beta freeze, we might reconsider. Other opinions?

[Scott Kitterman (kitterman)]

I think certainly no for now. I'd be willing to reconsider if the package
is fixed up, but this doesn't sound like a high priority for this release.

[Scott Kitterman (kitterman)]

I discussed this and related packages with ubuntu-release and I think it'll be OK if we can get an acceptable package. Please get 2 acks from MOTUs on the package and then say so in this bug and we'll reconsider at that point.

[Lars Heill (heill)]

From the above and a separate mail thread also involving glassfish, I gather these are the points various comments refer to - please correct me if I miss anything:

1. Missing binary dependencies: should have dependency on the package "java2-runtime" and optionally suggest sun-java5-jre | sun-java6-jre | icedtea-java7-jre | openjdk-6-jre ?

2. Java library packages should be called (e.g) "libsun-javadb-core-java" (dashes acceptable?).
    ==> must the binary package be split if it contains not only jars, but also has e.g [platform independent] user utilities in ./bin? (concerned, since this would break 1:1 package mapping across platforms) It looks like NB6 has done this, but cannot check details at the moment.

3. Java libraries (class files in jars) should be in /usr/share/java, one for each jar the product/package delivers, e.g
        [libsunjavadb[-client]] -> lib[sun-javadb][-client]-[fullversion].jar
    ==> would also need /usr/share/javadb/lib/derbyclient.jar soft link to one of these to not break default user utilities in /usr/share/javadb/bin, documentation and demos, and avoid causing general confusion among "veteran" Java DB/Apache Derby users and deployers.
    ==> how should all these lib*-<fullversion> jars be shipped and maintained? must all be included in later packages? should upgrade of the lib*-java package not uninstall the old versioned jars while installing the new versioned jars? Or would I *have* to use the package name construct libXXX[version]-java for this, e.g to keep Java DB 10.3 and 10.4 jars apart? - could be a lot, should there be a need for many [fullversion] bug fix releases - and how should these be phased out?
    ==> http://www.us.debian.org/doc/packaging-manuals/java-policy/x105.html is not consistent in its use of package and jar file versions: fullversion or version? E.g for Java DB fullversion = 10.3.2.1, but the "compatibility" (functionally equivalent) version would be 10.3 (which first came with 10.3.1.4).

Please also note:

  a. comment 3) under http://revu.tauware.de/details.py?upid=1972: Java DB is a rebranded distribution of Apache Derby and brings the unmodified binaries from Derby, in the customary Derby layout. (which would put it in multiverse)

  b. Java DB is not just a library, it is a full-featured database.

  c. The DLJ license does explicitly NOT prohibit the exclusion of the Java DB bits (in the db/ subdir) from sun-java6: http://download.java.net/dlj/jdk6/README.html#redistribution. sun-java6-javadb could be dropped altogether, and the corresponding bits ship with another package.
sun-javadb should replace the sun-java6-javadb package in multiverse (which breaks all items 1-3 above). They are the same thing, but only the former will update in synch with the Apache Derby community releases and that co-packaged with Sun's JDK releases. The latter is a remnant of a quick integration of the DLJ JDK bundle for Feisty.

[Emmet Hikory (persia)]

While I'm slowly becoming convinced of the value of this package as separate from other packages, and perhaps useful for hardy, I wonder why using a rebranded package in preference to that provided by http://db.apache.org/derby/ (perhaps with patches of various sorts) is desireable. How does the rebranding help Ubuntu?

[Scott Kitterman (kitterman)]

Please move the discussion to REVU and see if you can get the package in an
acceptable shape for inclusion. Once that's done (two MOTUs advocate), come
back to the bug and let us know.

[Lars Heill (heill)]

I am currently in India with limited bandwidth, so just some quick notes - I am not sure I am ready to move this to REVU just now, as I am not comfortable that I have been able to communicate what Java DB (or Derby) is ;) (sorry about that...)

It is *not just a library*. It is the leading [open source] Java database (like MySQL is the leading non-Java OS DB). Yes, it is *also* embeddable and other applications can embed derby.jar's classes.

While probably not the right forum, why does the Java packaging policy insist on renaming and moving jars? jars are not just libraries, they are also applications/executables 'java ... -cp foo.jar' (like in Java DB/Derby). Finding the jars renamed and moved out of the product home directory would probably be somewhat confusing to users - and break both docs and user utilities for Java DB/Derby.

Some comments re why Java DB over Apache Derby:

  * The Derby community is rather keen on keeping Derby platform independent, and I would not expect the community to provide platform specific packaging - that is where Java DB can help you as Sun does just that

  * Java DB is supported by the NetBeans IDE out of the box, used by the GlassFish application server and distributed with Sun's JDK 6 and should be there in this Java development to deployment environment.

  * You can buy enterprise 24/7 support for Java DB (but not if you run on binaries not 1:1 with the Java DB/Derby releases (which are in 100% sync)).

By the way, Derby has build dependencies on other binaries like junit.jar (in Ubuntu, 4 different packages), DITA-OT1.1.2.1_bin-ASL.zip (not in Ubuntu), JSR169's jars (not in Ubuntu), and JDK 1.4.x (do not know the status of building Derby with the Blackdown Java binaries in Ubuntu, never heard of anyone trying it) - see http://db.apache.org/derby/dev/derby_source.html. These would also need to be made available if a Java DB/Derby Ubuntu package were to be built from source.

Without having the above points clear, I fear a revu/motu discussion risk being in vain. Perhaps an offline discussion could be more fruitful?

[Scott Kitterman (kitterman)]

I think I'm good with it in concept, but there needs to be a package that's
ready for uploading.

[Gerardo Curiel (gcuriel-deactivatedaccount)]

Please read my last comment about the bug 188962 in https://bugs.launchpad.net/ubuntu/+bug/188962

[Lars Heill (heill)]

Updated package on REVU: http://revu.tauware.de/details.py?package=sun-javadb

[Matthias Klose (doko)]

looking at the licenses there is no reason not to upload the package to universe, so that it can be used with openjdk-6 or icedtea-java7 as well. The major thing which needs to be done for an upload is a build from source.

- include the sources in the .orig.tar.gz, or maybe use the db-derby-10.3.2.1-src.tar.gz file from the apache derby website?

- build from source using openjdk-6; please take care to adjust the build dependencies.

- is there anything in javadb which requires all files to be located in /usr/share/javadb? If not, then please follow the FHS for file locations.

- please rename the -docs package to -doc (there are a few -docs packages, but -doc is much more often used).

- the api docs should be placed in the docdir in a subdirectory called api, as all other packages providing api documentation do.l

- if there are application-only jar files, which are never used by any other application, you do not need to put these into /usr/share/java.

- demos should be placed in the docdir, the subdir is called `examples' in debian.

- doc files should be placed in the docdir, not in /usr/share/javadb

[StefanPotyra (sistpoty)]

I'm sorry, that this one has been delayed for quite some time.

setting back to new, to have other motu-release members take a look.

Given the comment of Matthias, I don't see a reason to reject the FFe, ACK #1 from me, given that you fix the aforementioned comments. Thanks for your patience.

[Lars Heill (heill)]

Thanks, Matthias and Stefan!

First: building from source is not an option at the moment, but possibly later (e.g for 8.10) because:

  * Java DB is (currently) only distributed as a rebrand of the the Derby binary distribution ("build once, run anywhere"...)

  * Building from source would require not only the Derby source tarball, but also other binaries not all available in Ubuntu (see above comment of 2008-02-26), and implementations of JDK 1.4, 5 and 6 - the Blackdown 1.4 in Ubuntu is a great unknown.

In general, the original tree and file structure from the Derby binary distribution should be preserved under /usr/share/javadb:

  * a must for the binaries in bin and lib to not break functionality

  * documentation structure should be preserved to not break links - but implemented through softlinks to contents located in the docdir

New packages will be uploaded later today or tomorrow with the following changes, as requested above:

  * docs, demo, javadoc moved to docdir, softlinks to them in /usr/share/javadb

  * softlinks in docdir added: examples -> demo, api -> javadoc (using softlinks should be ok?)

  * -docs package renamed to -doc

[Lars Heill (heill)]

Updated package on REVU:
http://revu.tauware.de/details.py?package=sun-javadb

[Daniel Holbach (dholbach)]

Matthias and I ACKed the latest upload on http://revu.tauware.de/details.py?package=sun-javadb

[Scott Kitterman (kitterman)]

Ack from me.

[StefanPotyra (sistpoty)]

please go ahead and upload.

[Lars Heill (heill)]

Thanks, all!

Just to be sure: this bug has (at least) two acks, and the package on http://revu.tauware.de/details.py?package=sun-javadb got two (though only one shows up in the table) and is ready for upload.

Since I am not a MOTU, I will just leave it to a MOTU to do the upload and complete the process, right?

[Martin Pitt (pitti)]

sun-javadb accepted from source NEW into hardy.

[nairbv (nairbv)]

The difference should be better documented in terms of what comes up in the package manager when selecting packages (the comments on the packages?).

When looking for derby.jar, I couldn't tell from the package manager what the difference was between the sun-java6-javadb and sun-javadb-* packages.

[Lars Heill (heill)]

sun-javadb-* (version 10.3) obsoletes sun-java6-javadb (version 10.2).

We hope to have the difference made clearer in the next spin.