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

["Tas Frangoullides" <tfrangoullides@xxxxxxxxxxxxxxxxxx>]

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

I think we are agreeing becuase you are implying a check to see if the TP 
already exists and if not then create it. This is what I mean by bypass.

Maybe where our view of target platforms differ only slightly is that 
although products with common TPs can just view it as dependency, there are 
many which have unique target platforms and for these products the TP 
creation step will be very cusomised.

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

Yeah. I understand this solution and it will work for RCP apps where all the 
code is under one location in subversion. However, if your products are 
split into many compoents each with their own subversion  trunk/branch/tag 
then it doesn't work so well. Buckminster is able to deal with this using 
rmaps but hudson just doesn't work this way. I think my workaround will be 
to have seperate builds for each component which then trigger each other, 
and use the approach you describe above for the component specific code and 
let buckminster resolve the rest. The nasty part is maintaining the build 
triggers to reflect you component dependencies.

Thanks,
Tas.