[buckminster-dev] Re: mspec problems with released buckminster

[Johannes Utzig <mail@xxxxxxxxx>]

Hi Carsten,

Carsten Reckord schrieb:
> Hi Johannes,
>
> On 17.07.2009 09:57, Johannes Utzig wrote:
>  > Great :). Your patch has been applied and a new version is released
>  > (0.8.3). Sorry for the weird versioning, the maven+java.net release
>  > process has so far been very troublesome for me but it should be all set
>  > now (I hope) and the next versions will follow a more 'traditional'
>  > version scheme.
>  > As a side note: try out the new version of the Warnings PlugIn, it
>  > supports buckminster compiler output now.
>
> I actually found another problem, only loosely related to the matrix 
> job. I would've entered a bug, but the hudson tracker doesn't know the 
> bucky plugin yet. Anyway, the problem is that while you set the 
> buckminster.output.root, the buckminster.temp.root still points to 
> /tmp/buckminster, which causes weird side effects when multiple 
> buckminster jobs run concurrently. Manually specifying 
> buckminster.temp.root seems to fix that so far...

Thank you for pointing that out, I'll fix that. I'll set 
buckminster.temp to ${WORKSPACE}/buckminster.temp I'd say. That will 
require more disc space than a shared temp directory, but if buckminster 
fails when running concurrently on the same temp directory it needs to 
be done.

> > About the buckminster job type, I aggree that it sounds nice. I'm just 
> > a little worried that this job kind would not be taken into 
> > consideration by other plugin developers (Buckminster is not quite as 
> > popular as Maven) and therefore most plugins would refuse to work with 
> > jobs of that kind (and what good is hudson without all the bells and 
> > whistles? :) )
>
> Well, I'm all for the bells and whistles of course ;) Maybe a subtype of 
> Freeform Project that just helps with the initial setup?

I'd like to hear more about that. Do you have anything specific in mind? 
How should the workflow look like?

> > The build trigger would be a very cool thing to have. The 
> > implementation would probably be very similar to the Ivy PlugIn 
> > because it essentially does the same thing. But how would we get the 
> > dependency information from Buckminster? Have it save a BOM or so?
> I'd start with assigning a "primary" CQuery to the Job that establishes 
> the job's "scope" wrt the involved artifacts. Then it should be fairly 
> simple to resolve that query against the target platform and workspace 
> (okay, those two would need to be established as well) in a 
> post-processing or build trigger plugin. The more complicated part that 
> I don't have a good answer to yet is which of these artifacts "belong" 
> to the job and which establish a dependency to another one. I.e. when 
> two jobs both have the same artifact materialized due to a (possibly 
> indirect) dependency from their primary CQuery, what does that mean for 
> their relationship to each other?

Yeah, that's not so easy...
I'd say a job only really produces artifacts if a perform action is 
invoked. We know on which components a perform action is invoked and we 
can probably find what the action output was. Now if a 2nd job resolves 
something that has a dependency to the action output of the first job, 
than I'd say those two jobs are dependant.

Btw: since you are also using Buckminster and Hudson together, would you 
mind having a look at the first (rough cut) of the Hudson+Buckminster 
tutorial and tell me what's missing yet? Thanks in advance.
http://wiki.eclipse.org/Building_an_RCP_application_with_hudson_(Buckminster)

Best regards,
Johannes