Hello,
I'm a maintainer of Nuxeo distributions.
We want to give Debian users an easy access to our open source (LGPL) products.
That means being able to publish Debian
packages into on of your repositories.
As far as I understand the case, the issue lies into the gap between two build
and packages' storage systems: the
rigorous Debian and the less-rigorous Maven ones.
The discussion title could have been: "How to package Nuxeo DM, a Java EE
application built with Maven, in Debian?".
About licenses and source code, there should have been more constraints on
Maven Central repository and other public
repositories such as: license being mandatory in POMs, simultaneous deployment
of JAR and source JAR, ... but that's not
the case, so it's Nuxeo responsibility to check for them and provide their list.
About versions and shared resources, sharing libraries is nice but not always
reliable and, tell me if I'm wrong, I
guess a lot of Debian applications are bringing their own unshared libraries.
There's no difference with JAR files.
Using a shared library is of course a good thing, not doing so is not always
bad, depending on the case and the
application level.
If there was a Debian-Maven base, we may be able to build Debian package
replacing JAR files in a Nuxeo product with
links to shared jars. There is not. So, bringing our JAR files into our
end-user application is keeping the OS sane and
isolating the libraries API to Nuxeo scope, avoiding conflicts, ..., keeping
the responsibility of maintaining what we use.
About Tomcat used by Nuxeo. You should not consider it as a "Tomcat" server but
a "Nuxeo" server based on Tomcat.
There's no point at reusing installed Tomcat, but there are good reasons to
include in Nuxeo sources the process of
building a "Nuxeo" server from a "Tomcat" one, that's why we do it.
Looking nearly at Nuxeo case, we build and produce about 374 JAR files
constituting the Nuxeo framework upon which our
products are built. Associated source files and build instructions are
maintained and documented by us, that's not an
issue to provide them.
But, we make use of about 416 third-party LGPL-compliant libraries, which also
rely on others, and others... at the end,
910 third-party JAR are used. That's the way Maven is working.
Listing third-parties and their licenses is fine for us. Looking for their
source code is feasible. Rebuilding all of
them, creating Debian packages and identifying common versions to Nuxeo, Debian
current and other JEE applications is
really too much work for us: you are asking for a bridge between Maven and
Debian repositories.
I fully understand Debian constraints. On the other side, I guess our
constraints are also valuable (about Java, Maven,
libraries' versions choice, being multi-OS, ...).
As Stefane said, Apache Maven is maybe the most used build system in Java Open
Source world. So, questions are:
* should Java products (built with Maven) be simply excluded from Debian
repositories ?
* do you have other Maven projects or large JEE applications in your
repositories ? If so, how are the Debian
packages built ?
If we cannot match the Debian repositories rules, because of the current
distance between Maven and Debian, isn't there
an "open-source partner repository" ? Maybe is it naive but I think it's much
more legitimate to get Nuxeo into Debian
than proprietary packages.
Last, because our case is probably not unique, going to Debian rules should not
reduce our product quality. If the
process of building a Debian package is not smooth enough to allow working on
the base of a multi-OS package (zip) and
requires a specific assembly, relying on specific shared libraries and
versions, then we are loosing quality and
increasing the risk of breakage. Such a process would be wrong.
Isn't it possible to make coexist Debian's stability and security,
cross-platform Java applications and Maven
collaborative software build tool ?
Thanks,
--
Julien Carsique, DevOps, Nuxeo (Paris, France)
www.nuxeo.com - The Open Source ECM Platform - www.nuxeo.org
Nuxeo ECM Stack - The Java EE, scalable, standard-based ECM Platform
