Code Organization

Roboconf’s source code is located among several Git repositories.
The way these projects were defined is related to their scope and the way we release these various parts.

Git Repositories

Impact on Releases

Every Git repository implies a distinct release process..
Although there are dependencies between them, their release is an independent process.

Roboconf-parent aims at being as stable as possible.
It should almost never be modified (once a year seems reasonable).

Roboconf-platform is a multi-module project.
All these modules must be released together. They must have the same version.

Roboconf-maven-plugin, Roboconf-system-installers, Roboconf-dockerfile and Roboconf-eclipse depend on modules from Roboconf-platform.
But still, they can be managed and released independently. does not need to be released.
It does not make sense. The web site contains documentation for the current and the old versions.

Roboconf-web-administration is downloaded and packaged into an OSGi bundle during Roboconf-platform’s build.
So, releasing it does not make sense. However, it may a good idea to tag it from time to time.

Roboconf-examples does not aim at being released.
As for the web administration, only tagging would make sense.

Other repositories do not need to be released.

Maven Modules

Here is an overview of the Maven hierarchy for Roboconf (not the file hierarchy).

├── roboconf-platform-parent
│   ├── roboconf-core
│   ├── roboconf-iaas-api
│   ├── roboconf-iaas-*
│   ├── roboconf-plugin-api
│   ├── roboconf-plugin-*
│   ├── roboconf-messaging
│   ├── roboconf-dm
│   ├── roboconf-dm-rest-api
│   ├── roboconf-dm-rest-client
│   └── roboconf-maven-plugin
├── roboconf-maven-archetype
└── roboconf-eclipse-parent
	└── ...

Some Git repositories, like, Roboconf-web-administration and Roboconf-examples do not contain Maven modules. Here is a little description of some platform modules.