PCM Development/Build Infrastructure/Github Repository 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.
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.
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:
|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.|
The folder structure for your whole project (consisting of many plugins, features, ...) should adhere to the structure suggested by Dirk Fauth  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)
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
- Generated source code from Xtend is stored in a folder called
These assumptions intentionally violate the prescribed project structure of Maven to better match commonly used Eclipse structures.
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/).
The topics we use on Github are:
|incubation||Experimental projects that are usually not yet shipped in Palladio releases.|
|third-party||Forked projects maintained or extended by Palladio developers.|
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:
|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||☐|
|Restrict who can push to matching branches||☐|