Re: [Fwd: Java standards for Debian]
On Fri, 7 Aug 1998, Paul Reavis wrote:
> I posted this to debian-java; doesn't look like anyone is lurking there.
> Could we move this discussion there?
OK. This one's cross-posted (I'm now subscribed to -java as well).
People on -devel who are interested should subscribe to -java now, future
threads will not crosspost.
> A first cut at proposed standards and needed tools for java under
> Debian:
Good work.
> 1) The classfiles and class resources for each installed library or
> application should be aggregated into a jarfile.
Agreed. Applications which shared code should have common code made into
a library package (as is the practice with normal programs, of course).
> 2) These jarfiles are placed in standard directories on the system like
> shareable libraries (Q - what should these be? I use
> /usr/local/lib/java/*.jar myself, but I'm no expert on the filesystem
> hierarchy).
Probably /usr/lib/java for shared files. jars which only belong to one
package have no business in a shared directory - I would tentatively
suggest /usr/lib/java/<packagename>
> 3) [debateable] classes in installed libraries should follow Java
> packagename standards and not be e.g. dumped into the top-level package
> (com.company... or org.organization... package convention greatly
> preferred, but there are lots of violations of that). This could be
> fixed by the debian maintainer for open-source products, but not for
> precompiled apps.
Precompiled apps go in non-free, and often don't conform to policy anyway.
But I agree that packagename standards should be followed.
> 4) A tool to include all installed jars on the system in the classpath
> before running Java would be useful; I have such a thing built from
> `find` and duct tape.
Hmm... I don't quite see why. Perhaps all 'shared' jars, yes.
> 5) A tool to build a classpath that includes only the desired jars
> before running Java would also be useful
>
> 6) some sort of mechanism for handling incompatible releases of a class
> library would be nice (but hard)
Agreed. Last I checked, java doesn't really have versioning support.
> 7) Each installed application should include a wrapper shell script, in
> standard form (possibly generated by a utility), that sets up the VM
> invocation and passes arguments through; this makes the javaness of the
> app transparent to users.
Absolutely. This is very important. It would go in /usr/bin.
> 8) Separate locations for the jarfiles for servlets, applets, etc. might
> be appropriate (they won't be called from the command line, typically).
I think they could probably still live in /usr/lib/java/<packagename>
> 8) Class libraries should include (possibly optional) documentation in
> JavaDoc or similar format. This can be automated with the build; perhaps
> a binary .deb, source .deb, and doc .deb would result from any
> open-source java product.
We don't do source .debs. We already have a perfectly good source format.
(OK, maybe it's not 'perfectly good', but we have one). Separate doc and
binary debs is often a good idea. Documentation would be in HTML format,
since that's what javadoc does. It needs a standard location, anbd then
packages like dwww need to be taught about it.
> Whaddayathink? I'll be glad to build some of these utilities, including
> a standard build process.
Good work. I suggest you sign up as a debian developer, personally.
Certainly, I suggest you spend a while learning about how debs are
normally built (unless you already know..) - you should see that some of
what you want is already well supported.
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: