What about saving it as a lib and creating a sim-link to it named
/usr/bin/saxon also?
:)
----- Original Message -----
From: "Mark Johnson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 26, 2001 1:53 AM
Subject: java packaging questions
> 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 <[EMAIL PROTECTED]>
> Debian SGML <[EMAIL PROTECTED]>
> Home Page: <http://dulug.duke.edu/~mark/>
> GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>
>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
