Do you follow any guidelines (java) in packaging?

Question

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.

Answer 1

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 <domain>.<application>.<module>.<layer>.<arbitrary substructure as needed> 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.

Answer 2

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:

aDelivery/
    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).

Answer 3

You can find a lot of information here:

What strategy do you use for package naming in Java projects and why?

Answer 4

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.