FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Java

 
 
LinkBack Thread Tools
 
Old 02-06-2011, 06:24 PM
Stefane Fermigier
 
Default How to package Nuxeo DM, a Java EE application, in Debian

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:

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 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.contentsdarkstar% 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."
 
Old 02-06-2011, 08:15 PM
Niels Thykier
 
Default 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+OCtwFG7U4VQ2CuVZHbLlLCaQhhhl 0n0it4TFNCzt+w
bQVK+5V2rh+FtIx9XVPv6N4ygkMdFNcS6MNyAoax843o6KjCVp jgfTpBcaMn1W7F
wWpe+RWm05WRBC0j7SlnUa13+XFboSvcR+qkuwLEnca0w7EfsP Ywwj8+ZrBafqPD
r22NhZLVbwsfodik1q/XxxnTr7cRliQDSetUdB86GUrwox0dYJ1OGAgvVjmZAo4E
RTSzpaYYx2kETWLPlZUAD2i/raznq5qYUDG96nz1MpIGpg7sh0ppBRX9H0qJZHXt
PqmEJniBZsFXerwLgaWQKXMy17eAsQTy3FMbms1WYTV28Ep/svrhHVoFm/8H4Phj
/9Ok1XDJJEnRVt63LGOxDi1QOkDm3X13037Ci9jf1SO9uR3VwCm 1AYBUZMpgAG0m
RnvurEk+oqdQH4y4OazPB0/eGrIEKnDy+LOUNykV6ioy5w8qXNbbLbwsF72TJSq+
/MwOGf+Qus8MfeQFnMMK3+x2nkFweG20o5qOUfuxRoYi7n0vpIK 2gOc9mC9/9CPY
T6CjzsRqUthHelaZ7Do5
=j8n8
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D4F0F79.9080001@thykier.net">http://lists.debian.org/4D4F0F79.9080001@thykier.net
 
Old 02-06-2011, 08:29 PM
Vincent Fourmond
 
Default How to package Nuxeo DM, a Java EE application, in Debian

On Sun, Feb 6, 2011 at 10:15 PM, Niels Thykier <niels@thykier.net> wrote:
>> 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.

I want to offer definite confirmation on this. We don't use embedded
JARs in a source package. We absolutely need every single package
compiled from source, and that includes their dependencies. That's why
packaging Java applications for Debian is so much of a pain ;-)...
More on that there:

http://vince-debian.blogspot.com/2009/03/java-packaging-nightmare.html

BTW, redistributing JAR files is not always a very good idea:
imagine you have a JAR of a (L)GPLed library, and for a reason or
another you lose the source (if only because you never had it as you
got binary JARs from upstream). Then, you fail the terms of the GPL
and cannot redistribute the JARs, since you would be at loss to
provide the source.

Cheers,

Vincent


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinMW-SZ1sJ=6ZDQVo1JVEwpZn7P8jT0WhWnKGqg@mail.gmail.com" >http://lists.debian.org/AANLkTinMW-SZ1sJ=6ZDQVo1JVEwpZn7P8jT0WhWnKGqg@mail.gmail.com
 
Old 02-06-2011, 09:10 PM
Stefane Fermigier
 
Default How to package Nuxeo DM, a Java EE application, in Debian

On Feb 6, 2011, at 10:15 PM, Niels Thykier wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 2011-02-06 20:24, Stefane Fermigier wrote:
>> 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.

Sorry if I made myself unclear: we DO use maven for building Nuxeo. Maven 2.2.1 to be precise (with lot of sensitivity upon the exact maven version, actually).

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

If there is a security issue in Application A, then it's Application A vendor to provide a fix for this issue, even if this issue comes from one of the jars embedded in it.

>> 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)?

Actually we don't change the Tomcat source code, but we add several more JARs to the Tomcat lib, for instance to add transaction control, OSGi support, H2 database with fulltext indexing support, etc.

These changes must be (for some reason that I trust my developers / CTO to be right about) done in a global way and change the tomcat behavior, at the risk of breaking the other webapps (that are usually just a WAR) that would be installed in the same Tomcat instance.

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

Which means to go this route we would have to support several different Tomcat version, which we haven't the resources to do.

>
>>
>> [...]
>>
>> 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.

IIUC, we don't trust this kind of automated dependency computation. The only dependencies we trust are the one we have validated through unit testing + integration testing + selenium testing + manual testing + community feedback on release candidates.

>
>> [...]
>>
>> 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.

The fact that a company or foundation is behind an application seems an orthogonal concern to me.

The problem lies with large (and complex) applications, which tend to be developed by companies or foundations.

>> 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).

Only one of them is:

darkstar# dpkg --contents openbravo.deb > /tmp/openbravo-erp.contents darkstar# egrep ".jar$" /tmp/openbravo-erp.contents
-rw-r--r-- root/root 250643 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-core/lib/openbravo-core.jar
-rw-r--r-- root/root 6608 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/dbmanager.jar
-rw-r--r-- root/root 65261 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/jakarta-oro-2.0.8.jar
-rw-r--r-- root/root 207723 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/commons-lang-2.1.jar
-rw-r--r-- root/root 324441 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/postgresql-jdbc3-8.2.jar
-rw-r--r-- root/root 718907 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/dbsourcemanager.jar
-rw-r--r-- root/root 26514 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/stax-api-1.0.1.jar
-rw-r--r-- root/root 486522 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/dom4j-1.4.jar
-rw-r--r-- root/root 474464 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/wstx-asl-3.0.2.jar
-rw-r--r-- root/root 242227 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/database/lib/commons-betwixt-0.8.jar
-rw-r--r-- root/root 6608 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-db/build/lib/dbmanager.jar
-rw-r--r-- root/root 422533 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-wad/lib/openbravo-wad.jar
-rw-r--r-- root/root 23328 2011-01-08 01:42 ./usr/share/openbravo-erp/src/src-trl/lib/openbravo-trl.jar
-rw-r--r-- root/root 443432 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/antlr-2.7.6.jar
-rw-r--r-- root/root 92015 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/antlr-runtime-3.0.jar
-rw-r--r-- root/root 11816 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/ant-launcher.jar
-rw-r--r-- root/root 307860 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jcommon-1.0.13.jar
-rw-r--r-- root/root 42492 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-pool.jar
-rw-r--r-- root/root 1599570 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/axis.jar
-rw-r--r-- root/root 216638 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.eclipse.emf.ecore.xmi_2.4.0.v200806091234.jar
-rw-r--r-- root/root 352668 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/log4j-1.2.8.jar
-rw-r--r-- root/root 45124 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/xmlrpc-client-3.1.jar
-rw-r--r-- root/root 188671 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-beanutils-1.7.jar
-rw-r--r-- root/root 456234 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.openarchitectureware.core.expressions_4.3.1.20 080910-1400PRD.jar
-rw-r--r-- root/root 2111580 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/batik.jar
-rw-r--r-- root/root 3555707 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jdtcore-3.1.0.jar
-rw-r--r-- root/root 34875 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/ws-commons-util-1.0.1.jar
-rw-r--r-- root/root 187370 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.eclipse.emf.common_2.4.0.v200806091234.jar
-rw-r--r-- root/root 109043 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-io-1.4.jar
-rw-r--r-- root/root 356519 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/mail.jar
-rw-r--r-- root/root 1311979 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jfreechart-1.0.10.jar
-rw-r--r-- root/root 1067396 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/iText-2.1.3.jar
-rw-r--r-- root/root 248383 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/tika-core-0.6.jar
-rw-r--r-- root/root 1223877 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/xercesImpl.jar
-rw-r--r-- root/root 104038 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/xmlrpc-common-3.1.jar
-rw-r--r-- root/root 411090 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/xstream-1.3.jar
-rw-r--r-- root/root 97704 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/servlet-api.jar
-rw-r--r-- root/root 313898 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/dom4j-1.6.1.jar
-rw-r--r-- root/root 46725 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-codec-1.3.jar
-rw-r--r-- root/root 27256 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-fileupload.jar
-rw-r--r-- root/root 56702 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jettison-1.0.1.jar
-rw-r--r-- root/root 559366 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-collections.jar
-rw-r--r-- root/root 29836 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.apache.commons.cli_1.0.0.jar
-rw-r--r-- root/root 94649 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.eclipse.equinox.common_3.4.0.v20080421-2006.jar
-rw-r--r-- root/root 660390 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jxl-2.6.jar
-rw-r--r-- root/root 244646 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.eclipse.text_3.4.0.v20080605-1800.jar
-rw-r--r-- root/root 26708 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/catalina-ant.jar
-rw-r--r-- root/root 3762982 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/hibernate3.jar
-rw-r--r-- root/root 3056 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/ant-apache-log4j.jar
-rw-r--r-- root/root 37064 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/lam-client.jar
-rw-r--r-- root/root 1465682 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/fop.jar
-rw-r--r-- root/root 58880 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.openarchitectureware.core.emftools_4.3.1.20080 910-1400PRD.jar
-rw-r--r-- root/root 52915 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-logging-1.1.jar
-rw-r--r-- root/root 31191 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jaxrpc.jar
-rw-r--r-- root/root 446063 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/quartz-1.6.2.jar
-rw-r--r-- root/root 143602 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-digester-1.8.jar
-rw-r--r-- root/root 208048 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/ehcache-1.2.3.jar
-rw-r--r-- root/root 160862 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.openarchitectureware.core.workflow_4.3.1.20080 910-1400PRD.jar
-rw-r--r-- root/root 324238 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/cglib-nodep-2.1_3.jar
-rw-r--r-- root/root 2082142 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jasperreports-3.0.1.jar
-rw-r--r-- root/root 324441 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/postgresql-jdbc3-8.2.jar
-rw-r--r-- root/root 158555 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/barcode4j-fop-ext-0.20.5-complete.jar
-rw-r--r-- root/root 126771 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/wsdl4j-1.5.1.jar
-rw-r--r-- root/root 73425 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/avalon-framework-4.1.5.jar
-rw-r--r-- root/root 105672 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/nekohtml.jar
-rw-r--r-- root/root 8812 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jta.jar
-rw-r--r-- root/root 436697 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/ant-nodeps.jar
-rw-r--r-- root/root 290823 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.openarchitectureware.core.xpand2_4.3.1.2008091 0-1400PRD.jar
-rw-r--r-- root/root 64731 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/hybridlabs-beautifier-1.1.9.jar
-rw-r--r-- root/root 960134 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/jalopy-1.5-rc3p1.jar
-rw-r--r-- root/root 1034902 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/org.eclipse.emf.ecore_2.4.0.v200806091234.jar
-rw-r--r-- root/root 55932 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/activation.jar
-rw-r--r-- root/root 1323005 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/ant-1.7.1.jar
-rw-r--r-- root/root 107631 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-dbcp.jar
-rw-r--r-- root/root 194354 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/xml-apis.jar
-rw-r--r-- root/root 1988051 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/ojdbc6.jar
-rw-r--r-- root/root 32784 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/axis-ant.jar
-rw-r--r-- root/root 250643 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/openbravo-core.jar
-rw-r--r-- root/root 5893 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/renderFoRmi.jar
-rw-r--r-- root/root 18979 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/saaj.jar
-rw-r--r-- root/root 71442 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/runtime/commons-discovery-0.2.jar
-rw-r--r-- root/root 361757 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/google-collections.jar
-rw-r--r-- root/root 871260 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/js.jar
-rw-r--r-- root/root 109043 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/commons-io-1.4.jar
-rw-r--r-- root/root 74204 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/smartsprites-0.2.1-alpha.jar
-rw-r--r-- root/root 812720 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/ob-rhino-1.6R7.jar
-rw-r--r-- root/root 850797 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/yuicompressor-2.4.2.jar
-rw-r--r-- root/root 261809 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/commons-lang-2.4.jar
-rw-r--r-- root/root 338488 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/commons-math-1.2.jar
-rw-r--r-- root/root 6662 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/YUIAnt.jar
-rw-r--r-- root/root 116799 2011-01-08 01:42 ./usr/share/openbravo-erp/src/lib/build/junit.jar
lrwxrwxrwx root/root 0 2011-01-08 01:42 ./usr/share/tomcat6/lib/tools.jar -> ../../../lib/jvm/java-6-sun/lib/tools.jar

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

Indeed, do you have examples of large scale (i.e. > 50 jars, > 50 MB) Java EE application that are already present in Debian, so we can look how the problems have been solved in their case ?

S.

--
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."


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 075EE681-C327-408D-9A80-6A1D1B1C8894@nuxeo.com">http://lists.debian.org/075EE681-C327-408D-9A80-6A1D1B1C8894@nuxeo.com
 
Old 02-06-2011, 09:17 PM
Stefane Fermigier
 
Default How to package Nuxeo DM, a Java EE application, in Debian

On Feb 6, 2011, at 10:29 PM, Vincent Fourmond wrote:

> On Sun, Feb 6, 2011 at 10:15 PM, Niels Thykier <niels@thykier.net> wrote:
>>> 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.
>
> I want to offer definite confirmation on this. We don't use embedded
> JARs in a source package. We absolutely need every single package
> compiled from source, and that includes their dependencies. That's why
> packaging Java applications for Debian is so much of a pain ;-)...
> More on that there:
>
> http://vince-debian.blogspot.com/2009/03/java-packaging-nightmare.html

Well, if packaging Java applications in Debian is a nightmare, shouldn't be Debian's responsibility to make it less of a nightmare to its developers or contributors ?

> BTW, redistributing JAR files is not always a very good idea:
> imagine you have a JAR of a (L)GPLed library, and for a reason or
> another you lose the source (if only because you never had it as you
> got binary JARs from upstream). Then, you fail the terms of the GPL
> and cannot redistribute the JARs, since you would be at loss to
> provide the source.

That's not how we do things in the Java world, especially when we are using Maven.

Note that when using Maven, those jars come usually from http://repo1.maven.org/, so the responsibility for providing the source code for these jars actually falls upon the owner of maven.org, which happens to be jvanzyl@codehaus.org - not upon us.

(But same for the pre-maven days when people used to embed third-party jars in a lib/ directory in their sources - with even less tracability for those jars).

S.

--
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."


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 64ABC203-ABE7-43FF-A908-C022B6907A8F@nuxeo.com">http://lists.debian.org/64ABC203-ABE7-43FF-A908-C022B6907A8F@nuxeo.com
 
Old 02-07-2011, 07:10 AM
Thomas Koch
 
Default How to package Nuxeo DM, a Java EE application, in Debian

Stefane Fermigier:
> On Feb 6, 2011, at 10:29 PM, Vincent Fourmond wrote:
> > JARs in a source package. We absolutely need every single package
> > compiled from source, and that includes their dependencies. That's why
> > packaging Java applications for Debian is so much of a pain ;-)...
> > More on that there:
> >
> > http://vince-debian.blogspot.com/2009/03/java-packaging-nightmare.html
>
> Well, if packaging Java applications in Debian is a nightmare, shouldn't be
> Debian's responsibility to make it less of a nightmare to its developers
> or contributors ?
As you write yourself below, "That's not how we do things in the Java world",
there is a clear and fundamental difference between the Java world and all
free software distributions (not only Debian).
Both sides have reasons, why they're doing things their way. Naturally I tend
to agree more with the points of the free software distributions. However you
can't just say that only the distributions should move (if they can at all
without violating licenses).
We're actively and hard working to resolve these issues. However java is free
only since 2007. Only then it started to make sense for free software
distributions to invest effort to resolve issues.
I'm aware of talks given at last years FOSDEM, German linuxtag and last
weekend's FOSDEM to raise awareness about the issues and discuss them. Inside
Debian people are building tools to make java packaging less of a nightmare.
However this all takes time.
I could now continue to express my anger about java developers which regard
windows as the "default development system", java developers who don't give a
shit about licenses or don't even know to tell the difference between GPL and
the Apache License, java developers who don't care that maven pulls jars
without any cryptographic protection, java developers who think it's good
enough if their code runs only against one specific point version of a library
and java developers who don't understand, why anybody should want to rebuild
their binary jars from source, - but I really shouldn't. :-)

> > BTW, redistributing JAR files is not always a very good idea:
> > imagine you have a JAR of a (L)GPLed library, and for a reason or
> > another you lose the source (if only because you never had it as you
> > got binary JARs from upstream). Then, you fail the terms of the GPL
> > and cannot redistribute the JARs, since you would be at loss to
> > provide the source.
>
> That's not how we do things in the Java world, especially when we are using
> Maven.
>
> Note that when using Maven, those jars come usually from
> http://repo1.maven.org/, so the responsibility for providing the source
> code for these jars actually falls upon the owner of maven.org, which
> happens to be jvanzyl@codehaus.org - not upon us.
As far as I understand the GPL, this statement is not correct. If you
distribute the jar, you also need to guarantee the availability of the source
code for the next three years. If the source code would not be available
anymore on some other site, you're f**cked.

> (But same for the pre-maven days when people used to embed third-party jars
> in a lib/ directory in their sources - with even less tracability for
> those jars).
>
> S.

Thomas Koch, http://www.koch.ro


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201102070910.33317.thomas@koch.ro">http://lists.debian.org/201102070910.33317.thomas@koch.ro
 
Old 02-07-2011, 07:42 AM
Stefane Fermigier
 
Default How to package Nuxeo DM, a Java EE application, in Debian

On Feb 7, 2011, at 9:10 AM, Thomas Koch wrote:

> Stefane Fermigier:
>> On Feb 6, 2011, at 10:29 PM, Vincent Fourmond wrote:
>>> JARs in a source package. We absolutely need every single package
>>> compiled from source, and that includes their dependencies. That's why
>>> packaging Java applications for Debian is so much of a pain ;-)...
>>> More on that there:
>>>
>>> http://vince-debian.blogspot.com/2009/03/java-packaging-nightmare.html
>>
>> Well, if packaging Java applications in Debian is a nightmare, shouldn't be
>> Debian's responsibility to make it less of a nightmare to its developers
>> or contributors ?
> As you write yourself below, "That's not how we do things in the Java world",

I should have added "in the open source java world" actually.

> there is a clear and fundamental difference between the Java world and all
> free software distributions (not only Debian).

That's what I wrote in the first email in this thread, if you remember.

> Both sides have reasons, why they're doing things their way. Naturally I tend
> to agree more with the points of the free software distributions. However you
> can't just say that only the distributions should move (if they can at all
> without violating licenses).
> We're actively and hard working to resolve these issues. However java is free
> only since 2007. Only then it started to make sense for free software
> distributions to invest effort to resolve issues.

The jpackage.org has been around for much longer than this. I remember it was already around in 2005, and I see it's been registered in 2001.

> I'm aware of talks given at last years FOSDEM, German linuxtag and last
> weekend's FOSDEM to raise awareness about the issues and discuss them. Inside
> Debian people are building tools to make java packaging less of a nightmare.
> However this all takes time.
> I could now continue to express my anger about java developers which regard
> windows as the "default development system", java developers who don't give a
> shit about licenses or don't even know to tell the difference between GPL and
> the Apache License, java developers who don't care that maven pulls jars
> without any cryptographic protection, java developers who think it's good
> enough if their code runs only against one specific point version of a library
> and java developers who don't understand, why anybody should want to rebuild
> their binary jars from source, - but I really shouldn't. :-)

I don't know those developers, I mostly hang with open source java developers actually

>
>>> BTW, redistributing JAR files is not always a very good idea:
>>> imagine you have a JAR of a (L)GPLed library, and for a reason or
>>> another you lose the source (if only because you never had it as you
>>> got binary JARs from upstream). Then, you fail the terms of the GPL
>>> and cannot redistribute the JARs, since you would be at loss to
>>> provide the source.
>>
>> That's not how we do things in the Java world, especially when we are using
>> Maven.
>>
>> Note that when using Maven, those jars come usually from
>> http://repo1.maven.org/, so the responsibility for providing the source
>> code for these jars actually falls upon the owner of maven.org, which
>> happens to be jvanzyl@codehaus.org - not upon us.
> As far as I understand the GPL, this statement is not correct. If you
> distribute the jar, you also need to guarantee the availability of the source
> code for the next three years. If the source code would not be available
> anymore on some other site, you're f**cked.

This is not 100% safe, but if someone asks me to provide the sources for a JAR and I can't find them, I can ask the same to Jason. Same if someone sues us.

So I guess in this case the root of all evil (like often in the Java world) comes from Maven...

S.

--
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."


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 70DB1D5B-DFB3-48EE-BAEC-07D806ED919B@nuxeo.com">http://lists.debian.org/70DB1D5B-DFB3-48EE-BAEC-07D806ED919B@nuxeo.com
 
Old 02-07-2011, 08:53 AM
Torsten Werner
 
Default How to package Nuxeo DM, a Java EE application, in Debian

Hi,

Am 07.02.2011 09:42, schrieb Stefane Fermigier:
> So I guess in this case the root of all evil (like often in the Java world) comes from Maven...

primarily from the (central) Maven repository which is not well
maintained. The software Maven is not evil but it has some issues, too.

Cheers,
Torsten


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D4FC108.9000204@debian.org">http://lists.debian.org/4D4FC108.9000204@debian.org
 
Old 02-07-2011, 10:21 AM
Vincent Fourmond
 
Default How to package Nuxeo DM, a Java EE application, in Debian

On Mon, Feb 7, 2011 at 9:42 AM, Stefane Fermigier <sf@nuxeo.com> wrote:
> So I guess in this case the root of all evil (like often in the Java world) comes from Maven...

I think the main problem is the "easy" management of versioned
depencencies. Software that allow the easy coexistence of a multitude
of versions of a library package (such as maven, but also rubygems,
that also hurts in Debian) encourage laziness: library developers tend
to care less for API/ABI changes ("If they don't like the new version,
they can use the old one"), and downstream developers tend to stick to
a well-known version and not make the effort to port to newer ABI.

Distributions cannot do that.

Cheers,

Vincent


--
To UNSUBSCRIBE, email to debian-java-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTimXCOdxq=kGU0oWQYKXC3G=cu+HUUGZ06eFAXMn@mail .gmail.com">http://lists.debian.org/AANLkTimXCOdxq=kGU0oWQYKXC3G=cu+HUUGZ06eFAXMn@mail .gmail.com
 
Old 02-08-2011, 04:34 PM
Julien CARSIQUE
 
Default How to package Nuxeo DM, a Java EE application, in Debian

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
 

Thread Tools




All times are GMT. The time now is 09:29 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org