PCM Development/Build Infrastructure/Github Repository Organization

Aus SDQ-Wiki
Zur Navigation springen Zur Suche springen

MDSD-Tools Organization

All MDSD-Tools source code is located in the MDSD-Tools Github organization.

Currently, there are no specific schemes and rules for contributing to this GitHub organization, but if applicable, follow the rules and schemes that are defined for the Palladio GitHub Organization below.

Palladio Organization

All Palladio source code is located in the PalladioSimulator Github organization. A rule of thumb is that there is a separate repository for every project that has an update site.

Naming Schema

To maintain clearness, we apply a naming scheme to all repositories and use Github topics to group repositories.

The naming schema is Palladio-Category-Name-Name2. Categories can be:

Category Description
Core Features that are essential for Palladio and can never be omitted.
Addon Features that introduce new features to PCM but that do not fit in any other category.
Analyzer Features that derive information about quality properties for given PCM models.
Simulation Features that provide the simulation framework for analyzing PCM models.
QuAL Features that record analysis results and provide analyses that derive quality metrics.
Editors Features that provide editors for PCM models.
Bench Projects that provide PCM features bundled read to use by users.
Supporting Features that do not depend on PCM but are used by other Palladio features.
Build Projects that support the build process including quality control of build results.

Folder Structure

The folder structure for your whole project (consisting of many plugins, features, ...) should adhere to the structure suggested by Dirk Fauth [1] in order to make life easier later. The suggested structure is as follows:

  • Project Root
    • bundles (contains all plugin projects)
    • tests (contains all test projects)
    • features (contains all feature projects)
    • releng (contains helper projects and the update site project)

Eclipse Plugins

We assume several usage pattern for developing Eclipse plugins.

  • Tests are stored in separate Plugin Test Projects
  • Source code is stored in a folder called test (restriction does not exist for Palladio projects)
  • Generated source code is stored in a folder called src-gen
  • Generated source code from Xtend is stored in a folder called xtend-gen

These assumptions intentionally violate the prescribed project structure of Maven to better match commonly used Eclipse structures.

Default Content

Every repository has to contain a LICENSE and a README.md file. The license has to be either EPL for Palladio contributions or Apache for build system contributions available via Maven Central.

The readme file has to adhere to the following template:

# Project name
Short project description (might be copied from the addon description in our wiki)

## Documentation
For comprehensive documentation, please visit our [wiki page](https://sdqweb.ipd.kit.edu/wiki/Palladio_xyz).

## Support
For support
* visit our [issue tracking system](https://palladio-simulator.com/jira)
* contact us via our [mailing list](https://lists.ira.uni-karlsruhe.de/mailman/listinfo/palladio-dev)

For professional support, please fill in our [contact form](http://www.palladio-simulator.com/about_palladio/support/).

GitHub Topics

The topics we use on Github are:

Topic Description
incubation Experimental projects that are usually not yet shipped in Palladio releases.
third-party Forked projects maintained or extended by Palladio developers.
build-system Build-related projects.

Branch Protection

We do not allow commits to master without proper code review. Therefore, we have to create a branch protection rule. Go to Branches and use the Add rule button to create a new rule. Use the following template for creating the rule:

Option Value
Apply rule to master
Require pull request reviews before merging
Required approving reviews 1
Dismiss stale pull request approvals when new commits are pushed
Require review from Code Owners
Restrict who can dismiss pull request reviews
Require status checks to pass before merging
Require signed commits
Include administrators
Restrict who can push to matching branches