[news.eclipse.tools.buckminster] Re: Automated Testing of RCP Products w

[Johannes Utzig <mail@xxxxxxxxx>]

Hi Tas,

Tas Frangoullides schrieb:
> Hi Johannes,
>
> I didn't mean that both command line and hudson would be running at the 
> same time. What I meant was that it is desirable to use the same scripts 
> during continuous builds as you do when you release the software. If you 
> split target creation away from your product build you'd need to make an 
> effort to structure your builds scrpits so that hudson can just bypass 
> this small test without needing to maintain it's own initial build 
> script. When a build in hudson works I want it to be as good a guarantee 
> as possible that a manual realase build will work.

In my opinion a target platform is an artifact the RCP build depends on 
not a side-product of the RCP build. Therefore it seems naturally for me 
to split those two apart. A command line build will have to do the exact 
same thing like the hudson build:
get the target platform from somewhere (it is either already there, or 
needs to be created) and make it known to buckminster (e.g. setpref 
targetPlatformPath).
So I don't really know what you mean by bypassing, if you have a script 
that does both tasks it is not much of a difference to having two hudson 
jobs. One builds a TP, the other uses it. In the hudson setup, the TP is 
referenced declarative, in the command line script it is referenced 
imperative. The result will be the same.

> Also, I think a big issue with hudson and rcp right now is one you 
> already know about: the way source code is checked out!

I don't see that much of a problem there. In my setup I do things the 
following: I have an rmap with a search path for the bundles to be 
built. There are two resolvers in that path, one that's using the SCM 
directly, the other is a local resolver that looks relative to the 
working directory. The local resolver succeeds only for the hudson build 
where hudson does the checkout and buckminster's working directory is 
set to the path of the workspace. On all other builds the local resolver 
will fail and the CVS resolver is used instead. That way I can make use 
of Hudson's SCM capabilities while still using the same queries and 
rmaps locally or in shell scripts.
You can of course let buckminster always do the checkout, but I 
personally like the change log generated by hudson.
As soon as I find the time to do so, I'll see what I can do to patch 
buckminster in a way that it's capable of CVS/SVN update and print out 
the change log, then I'll enhance the hudson plugin to use buckminster 
as a 'meta-SCM' and then you get the best out of both worlds.

Best regards,
Johannes