Re: Directory Structure for java
On Mon, 1 Jun 2009, Dan Smithers wrote:
I have inherited a Java project and would like to introduce a bit more
structure. I am C++ programmer and would like to know what is considered
good practice for Java.
Using ant or maven (which is ant plus some additional conventions) is
widely considered best practice. For small projects, it may be more
trouble than it's worth (and even for large projects, i've had maven in
particular cause real pain), but it's worth considering.
Currently there is a directory structure
project - contains .java files
com
astra
control - contains .java files
gui - contains .java files
utils - contains .java files
icons - contains .png files
JPEGS - contains .jpg file
All the sub-packages are compiled into one jar.
Is it a good idea to zip sub-packages as separate jars and then link
them together? There are other projects that could use these packages
and it would simplify maintenance.
That's the plus side. The minus is that it complicates the app - rather
than having one JAR, you have several. Mind you, if your app uses
third-party libraries, those have to be supplied anyway, so this may not
be such a big deal.
You could always build two targets, an all-in-one-JAR app, and the
reusable parts as separate JARs.
I would also like to add a build directory to reduce clutter in the
source directory, but when I try it I get a null pointer exception
accessing the icons directories.
I am compiling this as
javac -O -g -deprecation -d build *.java
and running from the project directory using
java -cp build VTASystem
If the images are being loaded as resources (through the
Class.getResource* methods), then they need to be on the classpath too
(bit weird, but that's how it goes). Do:
java -cp build:icons VTASystem
Assuming that the resource references are written relative to the project
root (/icons/foo.png, /icons/JPEGS/bar.jpg, etc), and that you're running
that command from the project root.
A convention for resources is that they should be organised in a directory
structure that mirrors that of the class files, so resources for your app
might be named /net/foo/vta/icons/foo.png etc. Note that this means that
your classes can then refer to resources via relative names, for instance
a class in net.foo.vta could ask for icons/foo.png (with no leading /) and
get the right thing.
You can then set up a directory hierarchy for resources parallel to the
one for source code, and as part of the build, copy all the resources into
the build directory before jarring that up or running from it. Something
like:
/
src/
net/
foo/
vta/
VTASystem.jar
lib/
lib1.jar
lib2.jar
resource/
net/
foo/
vta/
icons/
foo.png
Then:
rm -rf build
mkdir build
javac -classpath "lib/*" -d build $SOURCE_FILES
cp -r resource/ build
java -classpath "build:lib/*" net.foo.vta.VTASystem
Maven does this automatically, including converting character encodings of
text resources and things like that if needed.
If you're just running, this isn't really easier than using a separate
classpath entry that points to the resource root, but it's convenient when
you make a JAR.
tom
--
Initial thoughts - who cares? Subsequent thoughts - omg!!! (Female, 14,
Scotland) -- 4.5 million young Brits' futures could be compromised by
their electronic footprint, Information Commissioner's Office