S. Cambon
S. Cambon

Reputation: 560

Target platform versioning with Git in closed corporate environment

Context

We develop a number of plugins which are assembled into Eclipse RCP 3.X applications. We use a single target platform, which is based on P2 repositories because this is the only flavor supported by Tycho.

Target Plaform VS SCM

Our Internet access is quite restricted. We cannot access publicly available P2 repositories, even if we configure proxies. Therefore, we download P2 repositories zips and put them into source control so that they can be shared by the team and versioned. However, we think that having binary content under SCM is often a bad practice.

We are preparing to migrate from ClearCase to Git. While doing so, we are considering changing the way we manage our target platform for the better. We have thought about different scenarios but we lack experience to measure their pros and cons. Here are the first results of our reflections:

Scenario 1: Using a separate Git repository for the target platform

Scenario 2: Using Nexus with plugins for P2 repositories management

Questions

How do you handle target platform versioning with Git in a closed corporate network? What do you think about the above scenarios and their respective pros and cons? Could you suggest other solutions?

Upvotes: 1

Views: 177

Answers (1)

oberlies
oberlies

Reputation: 11723

Using Nexus and the Nexus Unzip Plugin, there is a very good solution that meets your needs of having a reproducible target platform and building independently of Internet access:

  • Set up Nexus, and make sure you have a m2 repository that you can deploy to, e.g. with deploy-file.
  • Download the p2 repositories you need as zip archives (or create these zip archives yourself if they are not offered for download).
  • Deploy the zipped p2 repositories to the Nexus m2 repository, using a non-SNAPSHOT version. Non-SNAPSHOT artifacts in Nexus are immutable, so when you reference the p2 repositories via their URL on Nexus, you'll always get the same content.
  • Install the Nexus Unzip Plugin and configure it to "shadow"/serve the content from the repository you have deployed to. In this way, the zipped p2 repositories get an "unzip" URL that makes them look like regular p2 repositories to Eclipse and/or Tycho.
  • Finally, create a target definition file referencing only p2 repositories in your Nexus, and put that file into your git repository.

We have been very successfully using this setup in our corporate environment for quite a while now, so I would recommend that you also try out this approach.

This is similar to your solution 2, but using a different Nexus plugin. You don't need any of the plug-ins for explicit "p2 repository support" for the described solution. Also, you don't need to do any additional archiving of your target platform content.


Disclaimer: The Nexus Unzip Plugin is offered by the Tycho project, of which I am a committer.

Upvotes: 1

Related Questions