-
Notifications
You must be signed in to change notification settings - Fork 0
Build and Continuous Integration
Our build and continuous integration / deployment is based on Maven, GitHub Actions and SonarQube.
Maven is used to build the projects, perform tests, create the packages and publish them. GitHub Actions are used for performing continuous integration and deployment by automatically executing the Maven build on the GitHub repository (pull requests, nightly builds and releases) and deploying the created packages to a snapshot or release (in case of a release tag) repository.
The Vitruv projects use a shared parent POM, in which the build process, including the used plugins, is defined. The (shared) dependencies of the modules inside a project are defined in the project's POM, while the used plugins are enabled for individual modules. A detailed description of the provided plugins, as well as their usage and the expected project structure can be found in the readme of the build parent POM. There is also a template project, showcasing and explaining the use of the build parent POM.
To check whether changes in one module break the build/tests of a dependent module, it is advisable to build the projects locally before opening a PR with the changes.
To do so, build the changed module using ./mvnw clean install, which places the built JAR in the local Maven repository.
After building the changed module, update the version of the respective dependency in the dependent module, if necessary.
For Vitruvius, the version is usually encoded in a Maven property called vitruv-change.version or vitruv.version.
Finally, build the dependent module using, e.g., ./mvnw clean verify.
Note: The changes to the dependent modules are just for local testing and should not be committed.
Example:
- Make changes to a module in the Vitruv-Change repository, which has the version (defined in the project POM)
3.2.0-SNAPSHOT - Build the repository using
./mvnw clean install - Update the version of all Vitruv-Change modules in the repositories Vitruv-DSLs and Vitruv by setting
vitruv-change.versionto3.2.0-SNAPSHOTin the project POMs (usually not necessary) - Build the repositories Vitruv-DSLs and Vitruv using
./mvnw clean verifyin both repositories
The Vitruv projects build on the Eclipse Modelling Framework (EMF) and were previously deployed as Eclipse plugins. While most EMF dependencies used in the Vitruv projects are now available on Maven central and the Vitruv projects are independent of the Eclipse IDE, we still need to support dependencies from p2 Eclipse updatesites. The mechanism for including p2 dependencies is described in the build parent readme.
Vitruv provides DSLs for consistency specification, more precisely the Reactions and the Commonalities language. These languages are defined with Xtext and consistency specifications written in those languages are transformed to Java code by the code generators of the languages. Since we do not commit generated code, this generation has to be performed by the Maven build. The plugins used for the code generation are activated and configured in the respective modules. The configuration is not part of the general parent POM, because it has to define the individual dependencies of the applications to which the languages are applied (i.e. the meta-models they use), which depend on the repository (e.g., the framework project uses example meta-models such as families and persons, whereas the CBS case study uses PCM and Java, requiring different dependencies).
We use GitHub Actions for performing continuous integration and deployment with workflows defined for each repository. Successful compilation and tests are a prerequisite for merging pull requests.