Hi, I'm new to this list, and I've joined specifically in the hope of finding a way to work with you guys in order to get our open source ECM software (Nuxeo CAP, DM, DAM, etc.), which are Java EE applications, into Debian. I'm already in touch with the Ubuntu guys, and I've tried to fast-track these packages into their "partner" repo, but it's not working as fast as I hoped, and, anyway, the end goal for us being to get maximal adoption for our packages, the best way for us is to get these packages accepted as official Debian packages someday anyway. 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 Debian (and other Linux Distribution, but that's another story). We have created packages 6 months ago that have been perfected with the help of our user community: 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 raised (by some Ubuntu guys) about 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 Debian 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 Debian 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 Debian / 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 Debian distribution just for 1 application?). I understand that these issues put us at odds with the Debian Java policies, and I understand mostly why these policies are in place coming myself from a Linux background (as a Slackware / Red Hat / Mandriva / Debian and Ubuntu user, and having made a few dozens of RPM packages in the past and a couple .deb). But I'm also convinced that the problems I'm mentioning are not specific to Nuxeo, but actually common to most large server-side Java (EE) applications. I don't know how many (if any) such applications have been already packaged into Debian. The only one I know is openbravo-erp from the Ubuntu partner repository (http://archive.canonical.com/ubuntu/pool/partner/o/openbravo-erp/), which already embeds 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. # Conclusion At this point, I'm asking for an opinion on how to work with the Debian/Java community to be able to: - bring more value to Debian users by providing them with free/open source enterprise-class applications - keep the high quality that is expected from Debian and its derivatives - don't ask too much effort (i.e. a few days of work is OK, a few weeks or months is too much) on my engineering team, and the Debian/Java team, to reach a common ground. -- 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." |