Take the 2-minute tour ×

Do you follow any design guidelines in java packaging?

is proper packaging is part of the design skill? are there any document about it?

Edit : How packages has to depend on each other?, is cyclic packages unavoidable?, not about jar or war files.

share|improve this question
what do you mean by "packaging?" Do you mean organizing your code into packages, or building jars/etc.? –  Andy White Mar 24 '09 at 4:42
Agree with Andy - is this about source code layout or the layout of what you ship as an application? –  TofuBeer Mar 24 '09 at 4:45
add comment

4 Answers

Packaging is normally about release management, and the general guidelines are:

  • consistency: when you are releasing into integration, pre-production or production environment several deliveries, you want them organized (or "packaged") exactly the same way

  • small number of files: when you have to copy a set of files from one environment to another, you want to copy as many as possible, if their number is reasonable (10-20 max per component to deliver), you can just copy them (even if those files are important in size)

So you want to define a common structure for each delivery like:

    lib // all jar, ear, war, ...
    bin // all scripts used to launch your application: sh, bat, ant files, ...
    config // all properties files, config files
    src // all sources zipped into jars
    docs // javadoc zipped 

Plus, all those common directory structures should be stored into one common repository (a VCS, or a maven repo, or...), in order to be queried, without having to rebuilt them every time you need them (you do not need that if you have only one or two delivery components, but when you have 40 to 60 of them... a full rebuilt is out of the question).

share|improve this answer
add comment

My approach that I try to follow normally looks like this:

  1. Have packages of reasonable size. Less then 3 classes is strange. Less then 10 is good. More then 30 is not acceptable. I'm normally not very strict about this.
  2. Don't have dependency cycles between packages. This one is tough since many developers have a hard time figuring out any way to keep the dependencies cycle free. BUT doing so teases out a lot of hidden structure in the code. It becomes easier to think about the structure of the code and easier to evolve it.
  3. Define layer and modules and how they are represented in the code. Often I end up with something like .... as the template for package names
  4. No cycles between layers; no cycles between modules.

In order to avoid cycles one has to have checks. Many tools do that (JDepend, Sonar ...). Unfortunatly they don't help much with finding ways to fix cycles. That's why I started to work on Degraph which should help with that by visualizing dependencies between classes, packages, modules and layer.

share|improve this answer
add comment

The problem with packaging in Java is that it has very little relation to what you would like to do. For example, I like following the Eclipse convention of having packages marked internal, but then I can't define their classes with a "package" protection level.

share|improve this answer
add comment

Your Answer


