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

[Achim Demelt <a.demelt@xxxxxxxxxxxxx>]

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.

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.

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...

Cheers,
 Achim


Johannes Utzig wrote:

> Hi Thomas,
> 
> comments inline as well
> 
> Thomas Hallgren schrieb:
>> Hi Johannes,
>> Comments inline...
>> 
>> Johannes Utzig wrote:
>>> !MESSAGE Missing requirement: Equinox Provisioning Engine
>>> 1.0.100.v20090525 (org.eclipse.equinox.p2.engine 1.0.100.v20090525)
>>> requires 'package org.eclipse.equinox.internal.p2.persistence 0.0.0'
>>> but it could not be found
>>>
>> This sounds like a regression of some kind. It used to work but it's
>> been a while since anyone tried it.
>> 
> I see :)
> 
>>> First of all, do you think a tutorial like that would make sense in
>>> the wiki?
>> Yes, absolutely. I think it's great that you do this. We are in a bad
>> shape when it comes to examples and tutorials so a contribution like
>> that is very valuable and appreciated.
>> 
> I'm glad you like the idea
>>> And if so, do you agree with the way I'm building things, or should I
>>> change something for the wiki page?
>>>
>> I agree that the sample should have an RMAP of its own but I'm not too
>> keen about using an approach where Hudson populates the workspace. By
>> doing that, you bypass the whole resolution/materialization piece in
>> Buckminster. Not so good if the purpose is to use it all as an example.
>> It would also impede future examples of more advanced features such as
>> CQUERY based branch/tag selection.
> 
> I don't think it's really bypassing. Materialization takes still place
> (kinda :) )since there is no workspace, just checked out modules.
> Resolution also takes place, just a simplified version with only two
> possible location: filesystem or target platform (other would be
> possible as well if you want for example some maven artifacts from your
> company's repository).
> The simple file-system resolution makes a lot of things easier for
> Hudson in my opinion:
> -you do not need to configure VCS credentials since this is done
> globally (by the administrator) in the hudson config
> -you get the change log on every build
> -the logs can be used to do advanced automated stuff like blaming test
> failures, updating bugzilla, report and changelog generation...
> -workspaces do not usually get deleted in hudson before/after a build
> and I'm not even sure if buckminster can do a cvs/svn update, or if you
> always have to do a full checkout (which is way slower). If it can, the
> only way to achieve this would be to maintain an additional mspec, or is
> there another way?
> 
> But I definetly do get your point, for an example it would make sense to
>   demonstrate the buckminster capabilities, I'm just not so sure if it
> really is the best, or rather, easiest approach in a CI server.
> 
>> 
>> Would it be possible to make Hudson understand that it should use
>> Buckminster as the check-out tool? Or perhaps we could make Hudson use
>> the information that it finds in a BOM file (the intermediate file that
>> Buckminster creates when it runs the resolver) to do the check-out?
>> 
> That actually sounds very interesting. I can't answer that just now, but
> I will think about how that could be done.
> However, if for example the buckminster hudson plugin would also
> register itself as as SCM plugin there's still the question I asked
> above: can buckminster currently do svn, cvs, perforce,... updates, or
> only checkout? Can the commit comments be retrieved? Can it be done
> without an additional mspec?
> Without commit logs, updates in favor of full check-outs and globally
> configured credientials, I doubt that many hudson users would do the
> check out with buckminster.
> But I definetly like the idea, and if you think that there is a way to
> preserve those features, then I'd be in.
> 
> About the later (using the bom to check-out) I'm not completly sure, but
> I don't think it will work because SCM plugins always run before build
> plugins run and all the check-out/update stuff is not done by the hudson
> core, but specific plugins depending on the SCM in use. I'll have a look
> but I don't think it could currently be done without changing a lot of
> hudson code for this very special use-case.
> 
> 
>>> To make the example really useful for people, the mail app would need
>>> to be buildable and I'd need the extra files available in SVN (see
>>> attached  patch). Would you be willing to apply the patch and
>>> eventually host the new cquery that points to the simplified
>>> local-resolution rmap (I'll deliver both if you are ok with my general
>>> approach) so that they will be available for public?
>>>
>> Yes, we'd be willing to do that. I think you should open a bugzilla
>> where you can paste a copy of this discussion and then attach patches.
>> The reason for that is that Eclipse.org cannot accept patches unless
>> they come as proper bugzilla attachments. An accepted patch also means
>> that your name is added to the contributor list of our IP-log.
>> 
>> Regards,
>> Thomas Hallgren
> 
> Ok, done. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=281503
> I hope it is ok like that...
> 
> 
> Best regards,
> Johannes