1

We have a full WSO2 environment set up and have been working with the WSO2 team. One question that has not been answered to our satisfaction is how best to manage the source code for various solutions created with the Eclipse WSO2 tooling.

For a little background, when you use the tooling to create a new solution, it will create a number of separate projects within the eclipse workspace. Our goal is to have "configurator" level developers able to easily fork and branch solutions our lead solution developers create and check into our on-prem BitBucket repo.

There are two approaches that we can see, each with their own drawbacks.

  1. Create a repository for the entire workspace and add .gitignore files in all the eclipse meta directories. This would allow another developer to check out an entire solution, but requires a lot of manually creating .gitignore files to prevent creating an eclipse workspace that might not load properly in a later version of eclipse.

  2. Create a repository for each individual project created within the workspace by the WSO2 tooling and manage each one separately. This makes branching or forking a challenge. Changes made to a solution would require committing changes on one or more separate repositories.

Has anyone else run into and subsequently solved this problem in an elegant way? Are we missing something obvious (please, oh please)?

Thanks in advance!

J E Carter II
  • 1,436
  • 1
  • 22
  • 39
  • I see some answers to this question from 2008: [https://stackoverflow.com/questions/337304/which-eclipse-files-belong-under-version-control] that come close to the mark, but there are some conflicting views on including .metadata as recently as 2015. – J E Carter II Feb 04 '19 at 18:19

1 Answers1

1

An easy way to organise WSO2 tooling code base is Maven multi-module project on the top level and then create Carbon archive project(CAR) for each server (ex: DSS, ESB/EI). Then under that, you can create ESB config and registry resource projects, etc. With this kind of approach, you only need to have one root level .gitignore and will help us to group project based on business use cases and easy to do the CI/CD as well. 

Top-Maven-project with module references 
  --> DSS CAR Project
      --> DSS project
      --> DSS Registry project
  --> ESB CAR Project
      --> ESB project
      --> ESB Registry project
Chandana
  • 2,578
  • 8
  • 38
  • 55