Hello folks. I would like to present jpackage project here, as it seems we have similar goals: 1 - to provide packaged java application for linux distributions 2 - to establish a clean fhs-compliant policy for them. See project homepage for further details (jpackage.sourceforge.net).
Concerning first point, we currently only provide mandrake and redhat rpms. However, we are open to any additional distribution support. To achieve this objective, we are specificaly designing a xml-based system to maintain only a generic and packaging system independant application information file, which is transformed into distribution specific spec file using xslt. Maybe some of you could be interested by reviewing/porting this to Debian ? All necessary files are in project CVS. Concerning second point, we would be happy to coordinate our efforts to establish cross-distribution standards. I had a look at http://lists.debian.org/debian-java/2001/debian-java-200109/msg00105.html in this list archive, it seems we already share most :-) Let me expose quickly our own practices: Package naming: - use standard package name (avoid uppercase, tough) - use full software name, plus major version for program requiring simultaneous installation - no distinction between libraries and applications - all api doc and manual should go in a distinct XXX-manual subpackage - all demo and samples should go in a distinct XXX-demo subpackage - applications using proprietary extensions should provide a main package with no proprietary library requirement, and a distinct subpackage with extensions, using manifest property system for automatically adding main jar to their classpath Jar naming - main jar should use package name - all additional jars should be prefixed by package name - only library and applications jars in /usr/share/java, all samples go with other data files in /usr/share/XXX - all jars use a versioned name with an unversioned symlink Running - applications launched from command line should come with a standardized start script, taking care of establishing classpath correctly. This may requires removing those class-path declaration from manifest file to avoid conflict - applications susceptible for being run by other programs should set automatically their classpath using manifest property system. - applications providing a common feature (as crimson and xerces-j) should use /etc/alternative system. application requiring this feature should use the alternative system rather than a specific application. Concerning JVM, we had no real discussion, altough there was a proposition to also use /etc/alternative system for the jvm itself, the compiler, etc... I myself joined debian-java, please also cc to jpackage-devel for other project participants. Thanks ! -- Guillaume Rousse <[EMAIL PROTECTED]> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
