java packaging questions

[Mark Johnson <mrj@debian.org>]

Hi All,

I package some of the DocBook XML stuff and want to package some java
xslt processing tools as well, but I'm not too clear on a few policy
points. Any help/suggestions would be much appreciated. Here goes:

1. Package naming, libraries vs. programs, etc.

   I recently uploaded an xslt processor package, lib-saxon-java,
   which follows the policy naming conventions in java-common 0.7:

     "Packages written in Java are separated in two categories:
      programs and libraries. Programs are intended to be run by
      end-users. Libraries are intended to help programs to run and to
      be used by developers. Both must depend on
      java-virtual-machine."

      [...]

     "There is no naming rules for programs, they are ordinary
      programs, from the user point of view. Libraries packages must
      be named lib-XXX-java."

   But saxon can be viewed as either a library or a program (if
   wrapper scripts are included.) Although I did follow the naming
   policy for libraries, many other packages do not. Is lib-saxon-java
   an appropriate name?

   Furthermore, since I'd like to make it easy for users to do XML
   processing (esp DocBook), I'd like to package some type of
   wrappers. Should I do this separately?  Or should I simply provide
   example scripts with lib-saxon-java for use with gcj and
   /usr/bin/java - type executables?

   I have similar questions for other packages I'd like to upload. The
   arbortext catalog classes (and related extensions) that provide
   catalog support for saxon and XT are an example. I could package
   the base classes as "lib-arbortext-java", the saxon extensions as
   "lib-saxcat-java" and make two more packages "xt-catalog" and
   "saxon-catalog" that provide wrapper scripts. Would such a
   combination be appropriate?


2. Package building: Is it necessary to recompile upstream jar files?

     I hope not. :-) 


3. Dependencies: The java-common policy states

     "Both [libraries and programs] must depend on
      java-virtual-machine."

   But many current java packages do not have this
   dependency. Suggestions?



Many thanks,
Mark

-- 
_____________________________________
Mark Johnson
Duke Physics        <mark@duke.edu>
Debian SGML         <mrj@debian.org>
Home Page:          <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4  89B2 BCBC B2C8 2BE2 FE81