Eclipse is a great platform for developing your own applications. However, once you want to share these applications with the community it becomes a bit trickier. Recently, we decided to bring our own project - “Virtual Satellite” - into the open source community of GitHub. Pushing the code to a repository is the first step. The next steps consider, continues integration, deployment, sharing of artefacts, maintaining code quality, etc. In this talk we present our architecture for an open source eclipse RCP application. First, we believe it will answer many questions others are facing as well. Second, we are still puzzling on some aspects we would like to discuss together.
To understand our needs for on open source infrastructure, we need to have a brief look into the project itself. Our project Virtual Satellite is not a single application. It is a family of RCP applications. Some are open source, and some are internal projects. The main part is Virtual Satellite 4 Core, a stand-alone RCP application, but it also provides P2 artefacts for other projects /RCPs based on it. Before we uploaded our code to GitHub, we did not start from scratch. We already owned a Maven/Tycho based build process including deployment into our internal infrastructure.
Our open source infrastructure provides a main architecture with optional extensions. The main architecture is built on GitHub, Sourceforge and TravisCI. All our source code is managed on GitHub. TravisCI is setup to build all feature branches, as well as our main development line. It also builds our integration branch and our releases once a new Tag is pushed to the master branch. On successful builds, TravisCI pushes only the final RCP applications back to GitHub Releases. The P2 repositories are pushed to Sourceforge, as GitHub Releases cannot handle them. Subsequent or internal projects can now access the P2 repositories on Sourceforge and download necessary dependencies. Other platforms for managing build artefacts created issues for daily and hourly development snapshot builds or were just incompatible to the P2 technology.
The extensions for the architecture contain all the extra bits for improving the whole development and quality process. One prominent example of these extensions provides test coverage analysis with CodeCov. We set up Github in a way, that the results of TravisCI and CodeCov, together with the jUnit, SwtBot, SpotBugs and Checkstyle tests of Maven/Tycho, are directly affecting if a Pull Requests can be merged into our main development. This GitHub’s branch protection helps us to enforce our GitFlow-like work-flow and to maintain code quality. Currently we are integrating automatic document generation with AsciiDoc and author verification to enforce Contributor License Agreements (CLA). All the technical details to this architecture are shared in our Virtual Satellite project, or in the Maven Tycho Demo on GitHub.
The described architecture helps us provide our software as open source. Uploading the code to GitHub and getting TravisCI running in a basic setup is very simple. Distributing P2 repositories was the main challenge. We are now managing it with Sourceforge. GitHub, TravisCI and Sourceforge is enough for a basic setup. All the other things around are extras improving the whole process.