Managing Multiple Projects with Repo

Managing Multiple Projects with Repo


In my previous post Creating a Scalable Application Ecosystem, I described how to create an ecosystem of applications, libraries, and services rather than isolated applications. With this paradigm, you should end up with smaller, more manageable projects, but how do you manage all of these separate codebases?

The Android project has this same problem in the extreme and to allow developers to easily work with multiple git repositories, they developed a tool called repo.

Repo augments git, allowing developers to download multiple projects with repo init, update a set of projects with repo sync, simultaneously create a branch across multiple projects with repo start and push all of the changes with repo upload.

The Apache Sling project uses repo to manage the 200+ modules making up the Sling codebase with significant success.

Bringing Repo to your Project

The first step to using repo on your project (after installing the tool) is to create a manifest XML file to describe the projects making up your application ecosystem. The basic structure of a manifest is as follows:

Repo Manifest Sample

The manifest itself should be in a separate project as a file in the project root called default.xml. The project only needs to contain the default.xml, but as this is the entry point for your codebase, adding a descriptive readme.md is essential. In the Apache Sling project we even used the project list in the default.xml to build out pages listing the modules and even showing project status.

Getting Started with Repo

To start using your repo project aggregator:

  • Clone the project
  • Run the command repo init
  • Run the command repo sync

This will automatically initialize, download and synchronize all of the projects in the repo manifest, initialize the project list.

Hopefully, this helps you understand how repo can support you to support building and managing an application ecosystem.


← New Release: AEM DataLayer 0.3.0 Mastering AEM Dispatcher Part 7: Securing the Dispatcher →