| Re: [tycho-user] Suggested build and releng scheme? |
|
Hi Jay, I can try to describe how we do it (building about 4 different RCPs each ~30 Features and about 300 Plugins). First of all, I have to
mention that we do not really care about versions because our customer do get the RCP as an installable zip/exe file. We are using the GIT/Gerrit workflow and we have about 15 git repositories. In each repository there is one conceptional feature of the product
we are building. For example, one of the feature of our product is, that our customer can write C/C++ code and so Eclipse CDT is part of our product, including some custom features file our own launcher, own toolchain etc. That conceptional feature we are
calling C-Developer. All of our plugins and features of that C-Developer are located in one git repository, other conceptional features are in other repositories. The structure of that repositories are all the same and look like that: -pom.xml (the aggreagation pom of all plugins/features/updatesite(s) for that repo) -plugins/foo.bar.plugin1 /foo.bar.plugin2 -tests/foo.bar.plugin1.tests /foo.bar.plugin2.tests -features/foo.bar.feature1 /foo.bar.feature2 -repositories/foo.bar.updatesite1 /Foo.bar.updatesite2 _In the root there is a pom.xml file which in an aggregation pom for all the plugins/tests/features and repositories of that git repository
(e.g. our C-Developer) _This aggregation pom is also the pom which our Jenkins Job is using. When Jenkins is building such a git repository, we have at the end different update sites for that conceptional feature (most of our
conceptional features do just have one update site, some do have more). If a conceptional feature do have dependencies to plugins of another conceptional feature, it uses the updatesite of that other conceptional
feature in its aggregation pom as p2 repository. One git repository contains our products (product update sites, installers). Within the pom file of such product builds, all relevant
conceptional feature update sites are listed as p2 repositories and the category.xml of such a product pulls in all required feature that should be part of that product. The product build is running nightly (~ 20min). The advantages of that setup: _Fast feedback for developers because just the conceptional feature has to be built on Jenkins for voting a change (~5-10min).
_Quite easy to handle feature branches for conceptional features Disadvantages: _When versioning is needed it might get complicated. (We haven’t thought about that yet) _Because the conceptional features are building independently you need a mechanism that takes care about incompatible API changes e.g.
API baselining or that a build of conceptional feature B gets triggered after conceptional feature A was changed if B depends on A. Hth Martin Von: tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-bounces@xxxxxxxxxxx]
Im Auftrag von Jay Jay Billings Everyone, Does anyone have suggestions on the best build and releng schemes for large RCP projects with Tycho? Right now we are using an aggregator with everything in it, including our products. Our products take about 20min each to build and the bundles take about 5 minutes. We build a full flavor of Eclipse in our products, so the product assembly
pulls in a lot of stuff. Just wondering how other people handle their product builds. Jay |