Apologies for cross posting this to both mail-lists, but I wanted to get
as broad a response about this from people using java & these are the
java-related groups that I'm subscribed to.
Anyways, what occurred to me during the new years break is to arrange my
java stuff into a file system along the lines used in linux systems
(unix in general?).
As it says below, this was all pretty much a thing that came to me and
sounded good as I jotted it down. I don't mean for this to be foisted
upon anyone, but it's helped me organise my files and I thought that if
other people liked the idea and wanted to use it then it might make life
a bit easier (or maybe it's a really stupid idea and everyone already
does it a better way) - in any case please let me know.
Thanks,
Maksim.
==
JFS - Java File System
This is the system I have decided to use for organising all my Java
related files. It is
based loosely on the linux standard filesystem organisation.
The highlevel directories are:
/-
|-/bin This holds all PLATFORM SPECIFIC executables used by java apps,
| including non-binary files like platform specific shell scripts.
|
|-/lib This holds all of the class files, arranged in directories as
per
| their packages.
|
|-/zlibThis holds class files which are packaged (and possibly
compressed) in
| zip or jar files.
|
|-/res This holds all "java-wide" resources such as icons.
|
|-/src As the name suggests this contains java source code. Note that
it
| can also hold non-java source code as long as that code produces
| java bytecode class files, e.g. JPython.
|
|-/doc This holds all of JavaDoc programming documentation for the
java
| code in the JSFS, note all USER documentation should go into the
| man dir structure and NOT here.
|
|-/tmp Location for temporary files created by Java apps.
|
|-/man Here goes all user documentation, manuals, howto, faqs, etc.
| A X-platform format such as HTML is preferred, although other types
| are exceptable as long as java-based readers are provided or
| are fairly X-platform, e.g. PDF, ASCII, (PostScript??).
|
|-/etc Here go all the (Java) system-wide config files these should
proferably
| use the java "properties" format so that a the config files are
| human-readable text and a nice graphical way can be provided for
editing
| any setting in a standard way.
|
|-/var And here go all of the config files used by java apps. These
should preferrably use the java's "properties" format.
Notes:
The root directory of the above structure can be anywhere. I currently
have the
above in a subdir called ~/Java, but I suppose having it is /usr/local
might be
a good system-wide place to put it on a *nix box (really it's not very
important
as long as there is some way to point the JVM to it).
Some things that I'm still not sure about is for instance should the JVM
go
into the bin directory heirarchy or should it be outside, in whatever
place the
underlying platform puts it's executables, at the moment I think it
should be
the later. Likewise for the standard JDK API classes, at the moment I
think
they should go in the zlib dir, but I'm not even sure if the concept of
the
zlib is a good idea, if it should be a top-level dir or inside lib (see
below
for more on this issue). It is a new concept, not one taken form
linuxs' FSS
so I'm on pretty shacky ground here, I'll leave it to time, experience
and
feedback to decide it's future. The res directory heiracrchy is another
one
where I have gone out on a limb. I think it would be useful to have
something
like this, where things like common icons, bitmaps, sounds, whatever
could be
stored for use by all java apps (again any comments on this would be
appreciated).
Another thing up for grabs with the lib & zlib directories is which
order the
should be searched by the JVM when looking for classes. At the moment I
suggest lib then zlib, since the main reason for having a lib (for me
anyway)
is the ability to quickly and easily drop-in replacements and new
versions of
class files that I'm working on. However with the availability of
virtual-filesystems to present a zip/jar archive files as if they are
part of
the filesystem (see the Midnight Commander program for what I mean) this
might
soon become a moot issue and the lib and zlib could be combined into a
single
lib directory containing _only_ archive files (the avoidance of
namespace
clashes in this case is an issue in it self).
Bugs:
I think that one problem with the above, in fact with systems in general
such
as linux and java, which have continually revised libraries is
versioning. On
unixy system
