[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ubuntu-devel
Subject:    How to package Nuxeo DM, a Java EE application, in Ubuntu?
From:       sf () nuxeo ! com (Stefane Fermigier)
Date:       2011-01-27 23:06:18
Message-ID: 3AB762B9-3A77-4CB9-ACA1-C5CEE0E41875 () nuxeo ! com
[Download RAW message or body]

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>



[prev in list] [next in list] [prev in thread] [next in thread]