Establish standard project directory layout
Discover and implement a standard Java project file structure to help developers gain understanding for the project quicker and to enable the use of common build and dependency management tools and IDEs.
* Adopt to standard Maven project layout as much as possible.
* Handle third party library distributions with a dependency management system. Only libraries not hosted in any of the public library repositories shall be distributed via the source code branch.
In general, a project directory structure should not be given by any kind of IDE or build tool. Beside some exceptions, there are common patterns and well-understood best-practices for the structure of Java projects [1,2]. The placement of any artifact should be made as clear and consistent as possible.
Although, I don't think Maven is the right tool to for Goobi by the time, it's clear and concise project layout has a lot of value . It has a good point in separating build results from sources and resources. Sub-projects and multiple programming language sources are also covered by this structure. Java developers quickly recognize the project structure and Tool vendors usually handle Maven project layouts very well.
Default directory layout allow for better tooling to be applied. Project structures for specific IDEs can be generated and updated automatically for project members working with Eclipse, IDEA or any IDE.
 Java EE 6 Tutorials, http://
 Guidelines, Patterns, and Code for End-to-End Java Applications, http://
* Separation of build artifacts, libraries and source code
* Build and test runs don't change any source code files
* Project can be cleaned to the state of initial checkout/branch
* Build results can be recognized and utilized by IDEs (e.g. in-place deployment)
The structure for build artifacts is different as might be imposed by build tool specifics and are not described by the specification.
Principal source code structure is 1) one directory per application module and 2) maven source code layout within the module directory. Project information or specific build files might be given to enable separate module builds.
│ ├── config
│ ├── java
│ │ ├── de
│ │ ├── dubious
│ │ ├── messages
│ │ └── org
│ └── webapp
│ ├── css
│ ├── js
│ ├── newpages
│ ├── pages
│ └── WEB-INF
│ ├── de
│ ├── dubious
│ └── org
source code of web application module
main module source code (web gui)
standard application configuration files
java source files
stylesheet source files
web content source files like JSP pages
static web content
dynamic web page source code
test source code
JUnit and functional test sources
static test data
(other modules will end up in separate directories like /src/cli or /src/server respectivly)
project documentation, installation instructions
libraries needed for compilation or execution but not provided by dependency
management (sub-folder per build task)
special runtime libraries
special deployment libraries
special build tool libraries
command line scripts needed to operate the application
install tools, database import files
- project can be loaded into Idea IntelliJ without problems. Web facets get detected. The web sub project is not shown as explicit sub project.
- Eclipse recognizes the web module but fails to configure project facets
It seems that structuring the source code the maven way already has positive impact on usability wit IDEs.
- lp:~zeutschel/goobi-production/standard-project-structure contains Eclipse configuration necessary to load the project within Eclipse JEE Edition. All project facets are detected and the application runs inside the IDE if Apache Tomcat Connector is configured.
restructure sources: DONE
check with IntelliJ: DONE
check with Eclipse: DONE
check with Netbeans: TODO
* Blueprints in grey have been implemented.