[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: jpackage project presentation



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?

> 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?

> 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?

> 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.

> http://lists.debian.org/debian-java/2001/debian-java-200109/msg00105.html in 

Yes that covers most issues.

> this list archive, it seems we already share most :-)
> Let me expose quickly our own practices:

The proposed policy is at:

http://people.debian.org/~opal/java/policy.html

> Package naming:
> - use standard package name (avoid uppercase, tough)
Same as we use.

> - use full software name, plus major version for program requiring 
> simultaneous installation
Same as we use. You have a better description of it, thanks. :)

> - no distinction between libraries and applications
In what way? There is a major difference. One can be runned directly and one
not.

> - all api doc and manual should go in a distinct XXX-manual subpackage
We use -doc for this, which is a debian practice.

> - all demo and samples should go in a distinct XXX-demo subpackage
That sounds like something that we could adopt.

> - 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?

> Jar naming
> - main jar should use package name
Same.

> - all additional jars should be prefixed by package name
Same.

> - only library and applications jars in /usr/share/java, all samples go with 
> other data files in /usr/share/XXX
Sounds like a good thing. We should adopt this. We have not talked about
examples at all.

> - all jars use a versioned name with an unversioned symlink
Same.

> 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.

> - 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?

> - 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.

> 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...

We say that the alternative system must be used for jvm.

> I myself joined debian-java, please also cc to jpackage-devel for other 
> project participants. Thanks !

Ok.

Regards,

// Ola

-- 
 --------------------- Ola Lundqvist ---------------------------
/  opal@debian.org                     Björnkärrsgatan 5 A.11   \
|  opal@lysator.liu.se                 584 36 LINKÖPING         |
|  +46 (0)13-17 69 83                  +46 (0)70-332 1551       |
|  http://www.opal.dhs.org             UIN/icq: 4912500         |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---------------------------------------------------------------



Reply to: