-
Notifications
You must be signed in to change notification settings - Fork 0
Build and Continuous Integration (Eclipse Projects)
Our build and continuous integration / deployment is based on Maven Tycho and GitHub Actions.
Maven (Tycho) is used to build the projects, perform tests, package plugins to features and create an update site for them. GitHub Actions are used for performing continuous integration and deployment by automatically executing the Maven build after pushing changes to the GitHub repository (pull requests, main changes and release tags) and deploys the new artifacts to our nightly or release (in case of a release tag) update site.
Maven executes the plugins defined in its configurations (pom.xml files) and automatically determines a build ordner from the dependencies. However, from a logical point of view, Maven Tycho performs the follwing four steps:
- Build plugins in the bundles folder
- Build and run tests in the tests folder
- Package plugins to features in the features folder
- Create an update site in the releng folder
Like in every Maven build, each project contains a pom.xml file, which defines the Maven plugins to execute for building the project. In case of our Tycho builds, we use pomless builds for most projects. This means that we defined the pomless extension for Maven in the .mvn folder of the repository, such that most of the projects derive a temporary pom.xml from the information defined in the MANIFEST.MF files of the projects.
The pom.xml files are hierarchically structured, as each of them can reference a parent POM, from which information like plugin configurations are inherited. The topmost parent POM of the repository is specified in releng/tools.vitruv.parent. That parent POM specifies the repositories, i.e. other update sites, on which this build depends. That parent POM finally dependens on the more general Vitruv parent POM, which is deployed to Maven Central. See the following sections for more information on that POM.
In the following sections we introduce information about the Vitruv parent POM, as well as about specifics of our Maven build. These specifics especially come from our requirement not to commit generated code, which requires the build to be able to generate metamodel code and especially to compile Xtext languages.
In the project Maven Build Parent, a parent POM is defined that is used for all Vitruv builds. It defines the configuration for all the central tools used in Vitruv and ensures that the appropriate versions of them are used in all of our builds. In consequence, each Vitruv project should define that POM as its parent.
To ensure that the parent POM can be easily used by each project, we deploy that POM to Maven Central. The deployment process is performed by hand activating the appropriate release profile. The process is described by Sonatype in the Performing a Release Deployment section. Currently @HeikoKlare has the appropriate rights to perform the deployment, so please contact him for gettings more information or the appropriate rights as well, if necessary.
The parent POM configures the necessary Maven plugins for Tycho, Xtend, Source Feature generation and so on. Additionally, it defines two profiles for specific situations that will be discussed in the following.
Our Maven builds automatically generates the source code from Ecore metamodels using MWE2 workflows- The Vitruv parent POM defines clean-mwe2 and execute-mwe2 profiles, which execute the MWE2 workflows at workflow/clean.mwe2 and workflow/generate.mwe2 if existing and generates code from defined genmodels. . Please take a look into the projects of the main Vitruv project to see how to define such an MWE2 workflow.
Our projects define and generate ordinary Eclipse update sites, which simply combine the features that are generated during the build and put them into categories. They also specify the source features to be available on the update site. Additionally, the Vitruv-Build-AggregatedUpdateSite project aggregates all individual update sites to a single that ensure that all the dependencies for all provided features can be resolved and that all version constraints can be met.
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 parent POMs of the individual repositories define a profile for that generation. The profile is not part of the general Vitruv parent POM, because the profile has to define the individual dependencies of the applications to which the languages are applied (i.e. the metamodels they use), which depend on the repository (e.g. the framework project uses example metamodels such as families and persons, whereas the CBS case study uses PCM and Java, requiring different dependencies).
A prototype for the DSL generation profile can be found in the parent POM of the Vitruv main project. The profile especially defines the xtext-maven-plugin. It needs to execute the Reactions and the Xtend language (and the Commonalities language, if used) all at the same time to ensure resolvability of resources/classes (that is really important!). You have to adapt the dependencies of that plugin to the specific needs of your applications. While the framework dependencies stay the same, you have to adapt the domain/metamodel dependencies to those of you application.
It is important that your dependencies are resolvable as Maven artifacts and not only from an update site, because the xtext-maven-plugin is not able to resolve them. Since we deploy our Vitruv builds only to p2 update sites but not to a Maven repository, other builds, like our Vitruv-CaseStudies, cannot easily resolve the dependencies. To circumenvent that problem, we added a dependency wrapper in the case study repository, which simply encapsulates all dependencies (both to the Vitruv framework as well as to DSL artifacts) in a simple plugin project. This wrapper can then be used as an ordinary Maven dependency in the xtext-maven-plugin of the profile for DSL generation. For an example how to define such a wrapper see the Vitruv Component Based System Application and the appropriate Parent POM.
We use GitHub Actions for performing continuous integration and deployment after every commit, as well as every day. Each repository executes its own workflows.
Please check that your contributions successfully compile with those workflows. Every pull request will be compiled and tested automatically as a preliminary for merging it. You can execute the tests of dependent projects against your local modifications of projects you depend on (such as executing the applications after changes to the framework) by calling Maven with arguments that set the path to the according projects relative to the root of your file system. The arguments for the different proejcts are -Dvitruv.change.path, -Dvitruv.framework.path and -Dvitruv.dsls.path. Note that you have to package the local dependency (i.e. the change repository, the framework repository etc.) first, e.g. using mvn package.
Note that we do not use Travis CI anymore.