Re: [tycho-user] How to mvn deploy to repo plugins (site) in one build a

[Mikhail Kalkov <mikhail.kalkov@xxxxxxxxxxxxxx>]

A completely different thought that occured to me was to have a go at this from another angle: If you used git submodules to checkout out different Tycho based projects and then built them together, you wouldn't have this problem.. I've heard / read about  git submodules but not yet tried used them - any opinions about this?

They're complex to use, so I would recommend avoiding them if possible and not making them a necessary concept for your build.
However, it can be helpful to use git submodules for some specific tasks, such as rebuilding everything in one shot.

The additional advantage to this would be that you could "feature branch" such different projects together - if I understand submodules correctly.

Git submodules needs to be modified (with a git commit/git push) whenever you want to consume another branch, so it's difficult to use them to automatically test feature branch.

 

We actually use git submodules to build Tycho projects from different repositories. Simplified, this looks as follows: gitrepoA contains pluginA, featureA, and eclipserepoA, whereas gitrepoB contains pluginB, featureB, and eclipserepoB. There is a dependency from pluginB to plugin A, and that's why gitrepoB has gitrepoA as a submodule. Components A and B are placed in own repos because they have own release cycles and are indeed developed by different teams. Whenever we want to step dependency from component B to A, a submodule is updated in a separate change and all the tests for component B are run. It is also convenient to have source code of component A checked out next to component B for debugging purposes. The fact that the whole build can happen in a single maven reactor run is also a bonus.

All-in-all, git submodules work well as long as you treat them "read-only", i.e. don't try to push change from a submodule. It is also important that target platforms and build environments of components A and B are sufficiently similar or else you would have to spend a lot of time configuring submodule builds. Finally, we plan to move to binary dependency once component A becomes more stable and we don't need to depend on officially unreleased commits any longer.

Kind regards,
Mikhail Kalkov