| Re: [tycho-user] Suggested build and releng scheme? |
Hi Jay,
For a one repository strategy, we use a maven profile [1] to remove the product from the default workflow
- default : plugins, feature, update site
- product: default + product + RcpTT tests
You can run the default build locally and for Gerrit, the product is then only built weekly or nightly.
Regards,
Benoit
1: http://maven.apache.org/
guides/introduction/ introduction-to-profiles.html
De : tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-bounces@
eclipse.org ] De la part de SCHREIBER.Martin
Envoyé : lundi 13 mars 2017 07:21
À : Tycho user list <tycho-user@xxxxxxxxxxx>
Objet : 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@
eclipse.org ] Im Auftrag von Jay Jay Billings
Gesendet: Montag, 13. März 2017 04:13
An: Tycho user list <tycho-user@xxxxxxxxxxx>
Betreff: [tycho-user] Suggested build and releng scheme?
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
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user