|
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:
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 |