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