Ainsi parlait Ola Lundqvist : > On Wed, Oct 17, 2001 at 08:25:11PM +0200, Guillaume Rousse wrote: > > 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). > > Yes it seems very similar. Is there any policy available on some > homepage? No for the moment, i wrote this on-the-fly :-)
> > Concerning first point, we currently only provide mandrake and redhat > > rpms. > > Ok. > > > However, we are open to any additional distribution support. To achieve > > this > > Well are theese packages used by RedHat and Mandrake or are they add-ons? I submitted all my package to Mandrake initially, but no one was ever included in contrib, whereas most of my other packages were. I think this is a mandrake policy concerning licensing: as long as they can't include an opens-source jvm in main distribution, they won't include depending package. Yes, there is kaffe, but it's hardly enough most of the time (even if i had been happily surprised myself). Concering distinct (meaning: before the merge) RedHat package (Henri, please correct me if 'im wrong), they are'nt included in RedHat, but they are official apache jakarta project rpms > > 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 > > Well what does this xml-file do? A informational package or an alternative > to the .spec-file? It's a .spec file ancestor, containing everything to produce the spec file, with distribution-specific part (this is only for mandrake, this is only for redhat, etc...) It's very similar to spec file now, as i only know of rpm packaging system, but the goal is the become independant. Then you use a distribution-specific template to produce a distribution-specifc spec file, retaining only pertinent part, adapting some details (as mdk suffix for mandrake releases), etc... If you want examples, check in project CVS on sourceforge. > > 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 > > That sounds like what I personally are very interested in. [..] > > - no distinction between libraries and applications > > In what way? There is a major difference. One can be runned directly and > one not. Is this definition always applicable ? And what is interest of distinction there ? > > - all api doc and manual should go in a distinct XXX-manual subpackage > > We use -doc for this, which is a debian practice. -manual was an apache foundation practice, seems we'll have to choose our camp :-) Another name that could be standardized in the javadoc directory name: some apps use 'api', other 'apidocs', etc... [..] > > - 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 > > Quite the same here. We have the main, contrib, non-free sections of our > archives forcing us to do this kind of things. > > What is the manifest property system? Is that possible in all jvm:s? When you have a manifest file with a Class-Path entry, all values there are automatically added to the classpath when loading this jar into class-path. However: - it's difficult to modify - you don't have any error message if a value isn't found - it only works for execution, not compilation And i must admit i didn't think to the second issue :-( It works for java2 compliant jvm (sun, ibm, blackdown), i don't know for java1 [..] > > 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 > > The mainifests are not used (yet) so we force people to write a > wrapper that starts the application. I think wrappers are definitely superior solutions as they provide: - more easily modification - command-line completion - more than just class-path setting - ability to use common function defined externaly, the same way as services script share /etc/init.d/functions on redhat systems. > > - applications susceptible for being run by other programs should set > > automatically their classpath using manifest property system. > > Not used. This is a problem that we have not solved. Does this really > work with java1 jvms? The idea behind this was the following: as a package requiring stylebook for building doesn't have to also requires xalan-j, which is already needed by stylebook, you should have to add xalan-j to your classpath manually, stylebbok should do it for you. But here again, i'm not sure it works for java1 :-( > > - 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. > > I think this is coverd by the main debian policy. Do you already used for java applications ? We use it for jaxp_parser, it is really useful. -- 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]
