[java] Package structure for a Java project?

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

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

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

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.

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.

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.

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

The way i usually have my hierarchy of folder-

• Project Name
  • src
  • bin
  • tests
  • libs
  • docs

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

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

The way i usually have my hierarchy of folder-

• Project Name
  • src
  • bin
  • tests
  • libs
  • docs

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

The way i usually have my hierarchy of folder-

• Project Name
  • src
  • bin
  • tests
  • libs
  • docs

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.

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