RPM and DEB packages are the common way of installing libraries and programs on Linux distros. It is difficult (often impossible) to suggest Java applications as JARs for an addition into any repository. We could use the previous packages as examples: http://rpm.pbone.net/index.php3/stat/4/idpl/11767683/dir/opensuse/com/jogl-1.1.1-12.4.x86_64.rpm.html However, it would be better to provide separate packages for JOGL and for GlueGen.
Well, it would be a 'nice to have' feature sure. But if it's not us maintaining such a beast, then it would need others to create releases in sync with our builds. IMHO this is not feasable. If we would do it, we would need all those target platforms setup, right now we can generate binaries on a generic platform, compatible with todays distributions. And our target distribution system is/will be a 'java style' method, now it's JNLP/Applets. We may add OSGI etc.
Hi (In reply to comment #1) > Well, it would be a 'nice to have' feature sure. > > But if it's not us maintaining such a beast, > then it would need others to create releases in sync with our builds. > > IMHO this is not feasable. > > If we would do it, we would need all those target platforms setup, > right now we can generate binaries on a generic platform, > compatible with todays distributions. > > And our target distribution system is/will be a 'java style' method, > now it's JNLP/Applets. We may add OSGI etc. The numerous changes in Java security since its version 1.6 update 10 are driving Java Web Start very difficult to use. OCSP is disabled by default which prevents the use of trusted certificates under Windows and Mac. It is almost impossible to run an application without a trusted certificate since Java 1.7 update 21. Lots of Java developers would like to concentrate on creating applications, not on writing bug reports and looking for workarounds to deploy their apps. I would like to reopen this bug report. RedLine RPM and equivalent solutions could be found to build DEB and RPM packages but in the Java way. I don't suggest to provide a package per distro. I suggest to provide a very few generic packages to keep the whole thing maintainable at our scale. We could provide an architecture-independent package and a few architecture-dependent packages for JOGL and GlueGen. We could support a very few architures as a first step, only i586 and amd64.
I would like to know Sylvestre's opinion about my suggestion.
I'm currently trying to use Redline RPM Pure Java Library and JPkg to make RPM and DEB packages. They both work with Ant and as they don't use native build tools (rpmbuild, dpkg, ...), they work on any platform supporting JavaSE: http://redline-rpm.org/usage.html https://github.com/leplastrier/jpkg-library If I succeed in making it work for my application, I'll update the wiki. On the long term, making RPM and DEB packages with those Java based tools seems viable. Bundling third party libraries into those packages with an application is considered as a bad practice as it drives the whole less maintainable.
I provided some instructions to create DEB and RPM packages in the wiki: http://jogamp.org/wiki/index.php/Foreign_Packaging Some GNU Linux distributions already provide packages for JOGL including Debian, Ubuntu, ALT Linux, Fedora, Red Hat, Mandriva, Open Mandriva, Mageia, SUSE, Open SUSE, ... As it can be very difficult to comply with the guidelines of all GNU Linux distributions, providing officially supported and well tested packages for those distributions seems to be hardly feasible.
The existing RPM packages put the JOGL JARs into /usr/lib/java/ (the native libraries are in /usr/lib/) and the existing DEB packages put them into /usr/share/java/ (the native libraries are in /usr/lib/jni/).