Thanks very much! Very helpful info.
Post by SCHREIBER.MartinHi 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
eclipse.org] *De la part de* SCHREIBER.Martin
*Envoyé :* lundi 13 mars 2017 07:21
*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
-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).
_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
_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
Billings
*Gesendet:* Montag, 13. MÀrz 2017 04:13
*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
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/tycho-user