[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-user] User Story - Component-oriented build system
|
Thanks Nick and Timo! This is one of the biggest pain points for our build as well: the lack of a simple, incremental, publishing mechanism, similar to remote maven repositories. P2 composite repositories seem like a good alternative.
cheers,
iulian
On Mon, Jan 14, 2013 at 5:22 PM, Nick Boldt
<nickboldt@xxxxxxxxx> wrote:
You can build the individual components in order, publish their p2 repos (update sites) onto a webserver, and composite those sites into a single site from which you can then build your aggregate site, product, or appplication.
That's what we do for JBoss Tools / JBoss Developer Studio, and it allows us to build the various components (~25 of them) in order or out of order (ie., in the maintenance branch when only a few of the 25 need to be rebuilt).
Jobs:
http://hudson.jboss.org/hudson/view/JBossTools/view/JBossTools_4.0.juno/
Published sites for staging:
http://download.jboss.org/jbosstools/builds/staging/
Composite site:
http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.0.juno/
Aggregate site built from composite:
http://download.jboss.org/jbosstools/updates/nightly/core/4.0.juno/
And then, JBoss Developer Studio (the product) is built from the aggregated JBoss Tools site, and we publish the results here:
https://devstudio.jboss.com/earlyaccess/
https://devstudio.jboss.com/updates/6.0/
Hope that helps!
Nick
On 01/14/2013 10:11 AM, Timo Rohrberg wrote:
Hello everybody,
I would like to share the following user story / use case description
with you, hoping that some of you might have some hints for how put an
appropriate system into practice.
We are developing a small component-oriented client/server application
based on Eclipse Equinox, RCP, and RAP which is constantly growing
(components are changed and new ones are added). The individual
components' API is also far from stable and thus version numbering of
components itself and their exported packages is also constantly changing.
Currently, we build the entire application on our Jenkins buildserver
with Eclipse Tycho using a reactor project referring the individual
components. There's a continuous integration build job which runs on
every commit on one of the components, and a nightly build job which
builds the entire application on a nightly base.
We would now like to move to a more mature and component-oriented way of
building the system and its individual releases. The ideas for our
release management system are as follows:
Development on the individual components is done on the TRUNK stream.
About four times a year, a release of the entire system (including all
its components at the particular point of time) is created. The TRUNK
stream is branched and a complete build is triggered. The result of this
build becomes the base repository of the release (i.e. the set of
components forming the release). Main development continues on the TRUNK
stream, but the new release stream is also maintained. This means, new
versions of individual components (with changes in minor and micro
segment) are created and need to be built for individual shipment to the
customer using the corresponding release.
Unfortunately, we did not yet find a way to put all this into practice
with a Tycho- and possibly Nexus-based build system. We would need to
build components individually at least for the release maintenance
streams, but probably also for the TRUNK stream. While this is possible
to a certain degree with Tycho (assuming that all dependencies can be
resolved via the local Maven repository), we need to make the build
components available for consumption by the system deployer. One idea is
to deploy them into a Nexus repository, but this seem a little awkward
as Tycho cannot consume those repositories and also access to it is not
that straightforward for the system deployer for downloading individual
components. Another idea is to host p2 repositories on a web server, but
those cannot be built incrementally, i.e. every single build of a
component needs to build the entire application keeping all unaffected
components in the same version which introduces a lot of redundancy...
So far we did not find an appropriate approach that fits all our
requirements. Maybe you guys do have any idea or hint?
Thank you for any comment.
Timo
--
Nick Boldt :: http://nick.divbyzero.com
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
