jpackage project presentation
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 <rousse@ccr.jussieu.fr>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
Reply to: