Workspace Model

Structure

Different project model parts are stored in separate project-level and module-level services (ModuleManager, ModuleRootManager, LibraryTable, etc.).

They're implemented independently, and the project model has no single entry point. This leads to code duplication and complicates bulk modifications of project model elements, since you need to manually track modifiable instances of the model elements or create special wrappers to do it (see IdeModifiableModelsProvider).

Serialization

There is no way to serialize the project model’s entire content in a binary format to cache it or pass it to another process.

Reuse

The project model interfaces (Module, Library, Facet, etc.) are highly coupled with the API that is only available inside the IDE process and its component management system. It is not possible to reuse those interfaces in other processes (e.g., inside the build process or inside the process that imports data from Gradle) or when the project hasn't yet been initialized (e.g., inside the New Project dialog).

Thus, separate representations of project model elements are necessary:

• JpsProject, JpsModule, JpsLibrary, etc. for the build process

• ProjectData, ModuleData, LibraryData, etc. for the importing process

All these places must be updated everytime something in the project model is changed.

Flexibility

The project model concepts were created for IntelliJ IDEA before the IntelliJ Platform accommodated a variety of languages. Many common interfaces like Module and Library still have Java-specific properties. This makes it harder to reuse them for other languages and technologies, and there is no simple way to create new language-specific concepts and use them in the model.

Entities

Types of entities in the storage are represented by interfaces extending WorkspaceEntity (see Entity Declaration). All operations can be performed on entities. Properties of entities may be of a restricted set of types only, see Entity Properties for details.

Storage

Their instances are stored in VersionedEntityStorage, which provides access to the current ImmutableEntityStorage, an immutable snapshot of the storage state which isn't affected by further modifications of the storage.

Modification

Modifying entities is performed via MutableEntityStorage. Modifications are performed on copies of the original entities, so they don't affect old snapshots (see Entity Mutation).

Relationships

Entities are organized into a direct acyclic graph by optional parent-child relationships. The storage maintains the consistency of such relations: if a child entity has a non-null reference to a parent entity, it is removed when the parent entity is removed or changed to point to a different child entity.

Symbolic (soft) references between entities are supported. It is also possible to link objects of arbitrary types with entities.