[buckminster-dev] Re: Tutorial for building an RCP from hudson

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Achim and Johannes,

Achim Demelt wrote:
> Johannes,
>
> I totally agree that the best strategy for integration builds is to have the 
> CI server checkout/update the source. Buckminster can populate the workspace 
> using a local resolver. This is much faster than having Buckminster perform 
> the checkout.
While it might be faster and give some advantages for the Hudson user, it also has serious implications:
1. The Hudson build is no longer the same build as you would run locally (reproducibility is key).
2. You no longer maintain the data about the SCM's in one place (the build model is scattered).
3. You cannot control the resolution/materialization with a CQUERY.
4. The list of material to check-out will be static.

Using Hudson to check out is perhaps faster but remember that the reason it takes a bit longer when Buckminster does it 
is that Buckminster doesn't maintain a list of things to check out. The list is computed dynamically. AFAIK, Hudson is 
not capable of doing that. This feature is of some importance since the developer that adds a bundle to a feature might 
have insufficient privileges to change the Hudson configuration.

> Having said that, I see the point in the example showing SVN checkout 
> instead of local resolution. Maybe we can have _both_ resolvers in the RMAP 
> and select the appropriate one using a resolutionFilter? It would default to 
> SVN checkout, but in the presence of a "integrationBuild" property, the RMAP 
> could then select the local resolver.
That's better, but you still need to maintain a static list and you still have issues with permissions.

I would much rather see a solution where Hudson can actually benefit from what Buckminster finds. Which makes me 
curious, what does Hudson need in terms of functionality in order to maintain its workspace + changelog? Perhaps it's 
not that hard to accomplish.

> I'd like to bring up another point for a _really_ comprehensive example: 
> target platform. I am a strong proponent for defining a target platform up 
> front that everybody, i.e. all developers and the integration build, compile 
> against. So the first step in a build process would be to populate the 
> target platform. We're currently using Buckminster to do this, although I 
> really like PDE's new target platform story. At the moment, though, it can 
> only deal with exact bundle versions, which is not really what I want. A 
> combination of Buckminster and PDE would be great. Maybe we can hook 
> Buckminster into PDE as a target platform source. I'll investigate that...
IMO, Buckminster now has an even better way to populate the target platform. Simply use the eclipse.import reader and 
the p2 materializer. The advantage is that the provisioning that takes place when you do it that way can be platform 
independent and very exact (based on the resolution). The target platform provision mechanism provided with PDE will use 
the planner when installing from a remote repository. The planner is unfortunately always bound to a particular platform 
configuration. The PDE provider must also be told explicitly what features to include from the repository.

Also, Buckminster will provision the target platform in parallel with the SCM checkouts. How's that for speed ;-)

Regards,
Thomas Hallgren