Re: How to package Nuxeo DM, a Java EE application, in Debian
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-02-06 20:24, Stefane Fermigier wrote:
> 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.
>
Hey and welcome, :)
I suspect a reasonable amount of the Debian Java people are either
recovering from the release of Squeeze or from FOSDEM. Anyhow, I have
taken the liberty of only replying to some of the things in your email;
hopefuly some other the rest will follow up on this as well.
> 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 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...).
>
Actually, most Java packages do not use the ./configure && make && make
install approach. Most I have seen tend to use ant or maven; ant is
rather well supported (assuming the build file is written sanely) and I
believe we got some very good support for maven2 as well. :)
That being said, I am not too sure about the progress on maven3, but
that is a different story. :)
> 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."
>
I have to admit, these objections applies to Debian too. One of the
issues with embedding other libraries/applications into another
application is that it makes it harder to for us to fix security issues.
Particularly we have to trace with packages that embeds what library
and check whether each of those packages have that vulnerability. I hope
you can see that this will not work very well us if a lot of our package
do that.
In fact, in my experience Debian tends to be more zealous about this
than Ubuntu.
> 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.
>
Could these changes possible by ported to the standard Tomcat (that may
require you to re-license your changes under Apache-2.0, which the
Tomcat upstream uses as I recall)?
Tomcat is one of the applications I really would prefer not having two
copies of in the archive. I tried to do a security upload of the old
tomcat 5.5 in Lenny a while back and we are still trying to find people
willing to test the changes.
> 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.
>
A lot of the Ubuntu contributors for Java also contribute to the Debian
Java team, which means that Ubuntu usually ships (about) the same
version as Debian has in the archive when Ubuntu starts its freeze. The
thing is that Debian usually do not release anyway near the same date as
Ubuntu since we have very different release processes.
>
> [...]
>
> 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.
>
We have had some similar experiences with this. In fact there was a
proposal at DebConf10 to assist us with catching some of these issues by
introducing something like a "SONAME" for Java Libraries.
In fact I hope we can go beyond that and actually implement something
similar to the "symbols" files we have for C/C++ libraries.
In case you are not familiar with the symbols files; we have files that
lists all the public symbols of shared libraries. They can both be used
to calculate the minimum dependency version based on which symbols an
application uses and also catch some API/ABI breakages.
> [...]
>
> 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.
>
Indeed; in fact any large application either with a company or a
foundation behind it usually have this kind of issue. Probably
distributions and upstreams here tend to have a conflict of interest here.
Personally I am having a very similar experience with the eclipse;
they still use parts of tomcat 5.5, old jetty libraries and does not
work with ant 1.8. At least for ant, it is because ant 1.8 caused a lot
of regressions, not sure about the other things since they also use
parts from tomcat6 and newer jetty libraries. >.>
> 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
>
Btw, I am not sure if that method works as intended if the package
merely symlinks to other jar files that are available in other packages
(not intended to undermine your example, which I have not checked - just
a heads up).
> 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.
>
I am not familiar with the Ubuntu partner repository and requirements
for using that, so if openbravo is from the partner repository I have
very little means to comment on the sanity of that package.
> # 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.
>
>
I am definitely hoping we can find a suitable solution to this. :)
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNTw94AAoJEAVLu599gGRCCA4P/1xUDzVcIPlAtiGhSaoQbZ/E
OuUQE6CvKavlv4WgCukCsc9/HbPs3tOR43kuP3hBFGN8oScbSKPn9t3ZIGC9GJU0
gMkoyM6CTK6ZuaHzZ5nma+OCtwFG7U4VQ2CuVZHbLlLCaQhhhl0n0it4TFNCzt+w
bQVK+5V2rh+FtIx9XVPv6N4ygkMdFNcS6MNyAoax843o6KjCVpjgfTpBcaMn1W7F
wWpe+RWm05WRBC0j7SlnUa13+XFboSvcR+qkuwLEnca0w7EfsPYwwj8+ZrBafqPD
r22NhZLVbwsfodik1q/XxxnTr7cRliQDSetUdB86GUrwox0dYJ1OGAgvVjmZAo4E
RTSzpaYYx2kETWLPlZUAD2i/raznq5qYUDG96nz1MpIGpg7sh0ppBRX9H0qJZHXt
PqmEJniBZsFXerwLgaWQKXMy17eAsQTy3FMbms1WYTV28Ep/svrhHVoFm/8H4Phj
/9Ok1XDJJEnRVt63LGOxDi1QOkDm3X13037Ci9jf1SO9uR3VwCm1AYBUZMpgAG0m
RnvurEk+oqdQH4y4OazPB0/eGrIEKnDy+LOUNykV6ioy5w8qXNbbLbwsF72TJSq+
/MwOGf+Qus8MfeQFnMMK3+x2nkFweG20o5qOUfuxRoYi7n0vpIK2gOc9mC9/9CPY
T6CjzsRqUthHelaZ7Do5
=j8n8
-----END PGP SIGNATURE-----
Reply to: