On this page:
- Folder categories
- Package prefix for Java source roots
- Modules without content roots: Collections of dependencies
See also, Configuring Content Roots.
Content root is a folder that contains all the files that make up your module.
A module can have more than one content root, however, in most of the cases one content root will suffice. (In certain situations, the modules without content roots may be useful, see Modules without content roots: Collections of dependencies.)
Content roots in IntelliJ IDEA are shown as or .
Folders within a content root can be assigned to the following categories:
(or source folders; shown as ).
By assigning a folder to this category, you tell IntelliJ IDEA that this folder and its subfolders contain source code that should be compiled as part of the build process.
In Java modules, the subfolders within the source roots represent your Java package structure.
You can assign a package prefix to a source root (e.g.
com.mycompany.myapp) instead of creating the corresponding folder structure within that source root (e.g.
com/mycompany/myapp). For more information, see Package prefix for Java source roots.
In the absence of the package prefix and the subfolders, a source root would represent the default package (an unnamed package).
- Generated source roots (or generated source folders; shown as ; in certain views the [generated] text marker is used) are similar to source roots. The difference is that the generated source roots are not suggested as target folders when performing the Move Class refactoring or using the Create Class from Usage quick fix.
Test source roots
(or test source folders; shown as ).
These roots are similar to source roots but are for code intended for testing (e.g. for unit tests). Test source folders let you keep the code related to testing separate from the production code.
Compilation results for sources and test sources, normally, are placed into different folders.
- Generated test source roots (or generated test source folders; shown as ; in certain views the [generated] text marker is used) are similar to test source roots. The difference is the same as between the source roots and the generated source roots.
(or resource folders;
shown as ; available only in Java modules) are for
resource files used in your application (images, various configuration XML and properties files, etc.).
During the build process, all the contents of the resource folders are copied to the output folder as is.
Similarly to sources, you can specify that your resources are generated. You can also specify which folder within the output folder your resources should be copied to.
- Test resource roots (or test resource folders; shown as ; available only in Java modules) are for resource files associated with your test sources. In all other respects, these folders are similar to resource folders.
(shown as ) are ones that IntelliJ IDEA "almost ignores".
Very limited coding assistance is provided for files in excluded folders. Classes contained in excluded folders don't appear in code completion suggestion lists, references to such classes are shown in the editor as unresolved. When searching, IntelliJ IDEA doesn't look in excluded folders, etc.
Making the folders whose contents are "less important" excluded may improve the IDE performance.
Normally excluded are compilation output folders.
Sometimes, you may want to assign a folder within an excluded root to a different category. For example, the Maven build output folder
targetmay contain a subfolder with generated sources (e.g.
target/generated-sources). To deal with this situation, you would make the
targetfolder excluded and mark
target/generated-sourcesas containing generated sources.
Package prefix for Java source roots
A package prefix specifies which Java package corresponds to a folder and can be assigned to the following categories of the Java source roots:
If specified, the package prefix acts as an equivalent of the corresponding folder structure which has to be created otherwise.
To illustrate, let's assume you are going to work with the
In the absence of the package prefix,
you would create the folder structure
in the corresponding source root folder (e.g.
The alternative would be to assign
src as its package prefix and
store the corresponding classes right in
Modules without content roots: Collections of dependencies
A module can be used solely as a collection of dependencies for other modules. In such cases, instead of specifying the necessary dependencies separately, you can add the dependency on the corresponding module.
A module used for such purpose, obviously, doesn't need a content root.