Package structure for a Java project?

JavaPackages

Java Problem Overview

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

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

Java Solutions

Solution 1 - Java

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,

Solution 2 - Java

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.

Solution 3 - Java

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

Solution 4 - Java

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

Solution 5 - Java

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.

Solution 6 - Java

The way i usually have my hierarchy of folder-

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

Solution 7 - Java

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

enter image description here

Categories
Recommended Java Solutions
Recommended Packages Solutions

Previous Solution:

Unit testing for C++ code - Tools and methodology

C++Unit TestingRefactoring

Next Solution:

Including one C source file in another?

CIncludeC PreprocessorCode OrganizationProject Organization

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionmawaldneView Question on Stackoverflow
Solution 1 - JavajohnstokView Answer on Stackoverflow
Solution 2 - JavalyconoView Answer on Stackoverflow
Solution 3 - JavadataAnalystView Answer on Stackoverflow
Solution 4 - JavaRajView Answer on Stackoverflow
Solution 5 - Javauser5425586View Answer on Stackoverflow
Solution 6 - JavapdevaView Answer on Stackoverflow
Solution 7 - JavaDeepak PatankarView Answer on Stackoverflow