Re: [Fwd: Java standards for Debian]
Jules Bean wrote:
>
> On Fri, 7 Aug 1998, Paul Reavis wrote:
>
> > 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).
Even the unshared code is best stuck in a .jar file IMHO (but doesn't
need to be in the shared dirs, of course).
> > 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.
This idea is a consequence of how I maintain things here; with real
per-package maintenance no real need. However...
> > 5) A tool to build a classpath that includes only the desired jars
> > before running Java would also be useful
What I'm envisioning here is something like the LD_LIBRARY_PATH, where
there is a (configurable by sysadmin for the default and by the user if
need be) set of shared dirs that jars are looked for in. The tool would
locate the actual pathname of a needed jar, so the wrapper script
doesn't have to know and e.g. a user or sysadmin could replace a
Debian-installed .jar file with a newer version by the simple expedient
of placing it in ~/lib/java or /usr/local/lib/java and setting their jar
library path so that those dirs appear before /usr/lib/java etc.
> > 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.
Perhaps we can deal with it for now with simple conventions - if we
have the classpath-builder I outlined above understand that if a wrapper
script
asks for a jar library named "foobar-1.1" then it can use either
/usr/lib/java/foobar-1.1.3.jar or /usr/lib/java/foobar-1.1.4.jar, but
not /usr/local/lib/java/foobar-1.2.1.jar.
Of course, this is some extra work for maintainers.
> > 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.
Or wherever appropriate (/usr/X11/bin might be appropriate for some
apps, I dunno). That can follow current Debian file system guidelines.
> > 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>
Definitely for shared libs. What about non-shared? Kind of depends on
what gets done on the webserver side to support applets/servlets. I'm
not a www-type java programmer, so have no strong feelings here.
> > 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.
I am ignorant :-) Not .deb, but source-package appropriate for building
.debs. I believe that consists of upstream source, diffs, and a .dsc
file?
> (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.
/usr/doc/packagename/api would be fine for javadoc IMHO. Unless there is
some reason to aggregate them in e.g. /usr/doc/java/*
> 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.
I need to do this yes; I am a Debian power-user, but not a developer,
mainly because I'm too much of a Javahead. Perhaps with some
infrastructure I'll be better able to contribute.
Thanks for the feedback. I'll keep working on this, but also I'll start
learning more about packaging and go ahead and build some prototype
tools - working name is "lava". Should have something ready in the next
week or two; those interested can kick them around a bit before we try
to formalize the policies and procedures.
--
Paul Reavis preavis@partnersoft.com
Design Lead
Partner Software, Inc. http://www.partnersoft.com
Reply to: