142

Whats the best practice for setting up package structures in a Java Web Application?

How would you setup your src, unit test code, etc?

Jonik
  • 80,077
  • 70
  • 264
  • 372
mawaldne
  • 3,919
  • 6
  • 31
  • 37

7 Answers7

118

You could follow maven's standard project layout. You don't have to actually use maven, but it would make the transition easier in the future (if necessary). Plus, other developers will be used to seeing that layout, since many open source projects are layed out this way,

johnstok
  • 96,212
  • 12
  • 54
  • 76
64

There are a few existing resources you might check:

  1. Properly Package Your Java Classes
  2. Spring 2.5 Architecture
  3. Java Tutorial - Naming a Package
  4. SUN Naming Conventions

For what it's worth, my own personal guidelines that I tend to use are as follows:

  1. Start with reverse domain, e.g. "com.mycompany".
  2. Use product name, e.g. "myproduct". In some cases I tend to have common packages that do not belong to a particular product. These would end up categorized according to the functionality of these common classes, e.g. "io", "util", "ui", etc.
  3. After this it becomes more free-form. Usually I group according to project, area of functionality, deployment, etc. For example I might have "project1", "project2", "ui", "client", etc.

A couple of other points:

  1. It's quite common in projects I've worked on for package names to flow from the design documentation. Usually products are separated into areas of functionality or purpose already.
  2. Don't stress too much about pushing common functionality into higher packages right away. Wait for there to be a need across projects, products, etc., and then refactor.
  3. Watch inter-package dependencies. They're not all bad, but it can signify tight coupling between what might be separate units. There are tools that can help you keep track of this.
mmmmmm
  • 32,227
  • 27
  • 88
  • 117
lycono
  • 1,094
  • 7
  • 10
  • 3
    In the reverse domain case ("com.mycompany"), is the "com" package usually empty except for the "mycompany" subpackage? – Alex Parker Feb 10 '16 at 21:16
48

I would suggest creating your package structure by feature, and not by the implementation layer. A good write up on this is Java practices: Package by feature, not layer

Ruli
  • 2,592
  • 12
  • 30
  • 40
dataAnalyst
  • 481
  • 4
  • 2
  • 2
    Thanks. This is what i was looking for to convey my thoughts to team – Pranalee Dec 13 '13 at 07:12
  • 10
    And if you wish to switch databases? Only have to look in 30 different packages. Move from SFTP to webservices? Again only have to look in 30 different places. Definitely not a fan. – SamuelKDavis Mar 11 '14 at 23:06
  • 1
    another example where packaging by layer has benefits: if you serialize classes to JSON (e.g. with gson), if those classes are obfuscated (e.g. by Proguard) (de)serialization will fail; you need to configure Proguard not to touch such classes - it is the easiest just to specify single package with all of them – jmuet Dec 19 '14 at 13:37
8
The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc
Raj
  • 778
  • 1
  • 10
  • 14
7

I usually like to have the following:

  • bin (Binaries)
  • doc (Documents)
  • inf (Information)
  • lib (Libraries)
  • res (Resources)
  • src (Source)
  • tst (Test)

These may be considered unconventional, but I find it to be a very nice way to organize things.

  • "These may be considered unconventional" They are actually unconventional and bad by the way ... – mahieddine Jan 21 '18 at 18:26
  • 3
    @mahieddine Why do you consider them bad? – Git.Coach May 02 '18 at 12:19
  • Well it wasn't me who stated that, but here are some of my thoughts: Your test classes are source code so the directory "tst" (most people don't abbreviate test btw) should be a sub directory of src (e.g "src" becomes "src/main" and "tst" becomes "src/test"). Also "inf" seems to include content that could be in "doc". – Nico Wawrzyniak Jun 12 '20 at 15:45
4

One another way is to separate out the APIs, services, and entities into different packages.

enter image description here

Deepak Patankar
  • 3,076
  • 3
  • 16
  • 35
3

The way i usually have my hierarchy of folder-

  • Project Name
    • src
    • bin
    • tests
    • libs
    • docs
pdeva
  • 43,605
  • 46
  • 133
  • 171