How to package Nuxeo DM, a Java EE application, in Ubuntu?

Thu Jan 27 23:06:18 UTC 2011

Here are some thoughts and questions about how to package a Java EE application so that it can be accepted in partner.

We have packages that have been created a few months ago, and would be really pleased if they could be included in Natty, so your help would be really appreciated.

  S.

--

# Problem statement

We want to package Nuxeo DM (see: www.nuxeo.org), an open source (LGPL) document management solution developed using Java EE, for Ubuntu (and Debian, and other Linux distributions).

We have created packages 6 months ago, that have been perfected with the help of our user community:

http://blogs.nuxeo.com/fermigier/2010/07/debian-and-ubuntu-packages-available-for-nuxeo-dm-532-stable.html
http://blogs.nuxeo.com/fermigier/2010/12/new-beta-nuxeo-dm-package-debian-ubuntu.html

We are fully aware that our packages are not built in a way similar to the way a Linux package is usually built (i.e.: ./configure ; make ; make install). But we believe that:

1. We don't have another reasonable choice for how to build these packages.

2. The issues (and discrepencies with the packaging guidelines for Ubuntu or Debian) are not specific to our project, but common to every project that uses Maven (which seems to be the most popular build tool for Java projects these days) as its main build tool, and more generally to every large-scale Java EE application (such as: XWiki, OpenBravo, Compiere, Open-Xchange, OBM...).

Here are the main objection that have been raise for the way we are making our packages:

1. "It looks like they're bundling their own Tomcat.  We haven't allowed
this in the past. Ask that they use our version"

2. "They bundle a TON of JARs, many of which we provide. We may be able to
work with this, but ideally you will want to use our jars where possible."

And our answers:

Point 1.

There are two issues heres:

a. We're not using a "stock" Tomcat distribution, but one "patched" by adding a few jars in the "lib" directory, which means that other applications which would like to use the same tomcat instance could end-up with unexpected behaviour.

b. We're not using any version of Tomcat, but the one that has been proven (by our test suite and manual QA process) to work properly. While it's probable that other versions of Tomcat could also work, we have no proof of it will unless we base our own "standard" distribution on the exact Tomcat version that's shipped with Ubuntu.

Point 2.

It's possible that some of the jars contained in Nuxeo DM are also provided as Ubuntu packages. We could spend more time trying to come up with a list of matches, but I think it is highly improbable that a great many of them would exactly match the version of the jars we provide in Nuxeo.

The problem is, we run our quality assurance process against and have our customers running on an application build from a list of very specific versions of these jars. It is possible that changing a jar version for another won't change anything in the application behavior, but we can't guarantee it, and our experience is that it is not just a theoretical issue, but something we run into every time we upgrade the version of one of our dependencies.

# Actions taken and issues encountered

We could do the following:

Issue 1.: We could make a script that would setup a separate tomcat instance based on the stock Ubuntu Tomcat package, and use it as the basis for the Nuxeo DM package.

BUT: this doesn't solve the fact that we would need to align our own development on the exact Tomcat version you are using, and support different Tomcat version each time you change it for a new Ubuntu release (at the moment, the same Nuxeo DM package can be used on several Ubuntu and Debian releases, as long as Java 6 is installed).

Issue 2.: We could create a .deb package for each of the 250 third-party jars that are contained in Nuxeo DM, at the expense of lot of time and additional complexity, but what would it gain? Each jar wold have to be named with its exact version number, because, and once again this is our experience, we don't expect that changing jar X.Y.Z to X.Y.Z' will never ever end up in some breakage somewhere. So eventually this won't probably gain us anything, because each of the Java EE application you could eventually want to package will have slightly different versions for all the jars that they have validated, and so you will end up with mutiple versions of the jars in a system that has several of these applications installed (or several copies of the jars in the packages repositories).

We understand that this looks counter-intuitive to the Linux / C / C++ developers, but our experience with open source Java development is that you have to be very careful about changing the version of your librairies.     

So, for both of the issues that have been raised, solutions exist that could address the lack of "purity" of our packages, but don't gain anything meaningful for the users (and probably add more complexity), while costing us a great deal of time, effort, and adding additionnal complexity and risk to our own development process (and probably yours too - do you really want to add 250 news packages to the Ubuntu distribution just for 1 application?).

# Asking for a solution to the community if none are found

Maybe you have solutions for the two points that have been raised. Maybe when packaging one of the other Java EE applications that I have mentionned (or some others) someone has found a better way to do it.

But at this point, the *only Java EE package* I see in your partner repository in openbravo-erp (http://archive.canonical.com/ubuntu/pool/partner/o/openbravo-erp/). Looking at the .deb, I seen they are embedding 92 jars:

darkstar% dpkg --contents openbravo-erp_2.50MP-25EU1-1maverick1_all.deb > /tmp/openbravo-erp.contents
darkstar% egrep "\.jar$" /tmp/openbravo-erp.contents| wc -w
   92

This is less than us (more than 250 third-party jars + 187 of our owns), but this is just because their application is less complex than ours, not because they are packaging it differently.

-- 
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20110127/db04b66b/attachment.html>