| [buckminster-dev] Re: mspec problems with released buckminster |
Carsten Reckord schrieb:
Hmm, that's weird, I can't find it any more. I was quite sure that I was reading something a while ago about the possibility to do that with wildcards if you include the platform settings (ws, os, arch) into the output path (so that things don't get copied on top of each other). But I might just have a faulty memory :)Hi Johannes, On 15.07.2009 19:07, Johannes Utzig wrote:I thought buckminster itself provider the means of building platform agnosticSlight misunderstanding here. What I'd like to do is not a platform-agnostic build, but several platform-specific ones, each with only those parts required for that exact platform.target.os=${*} ...I must admit that it never quite worked for me but I think there's something like that already implemented.
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.Thank you very much for the patch, that's what I thought needs to be done. I'll have a look into it, do some tests with matrix builds on my own and bump up a new version today or tomorrow if everything works fine.I'm looking forward to it :)Please let me know when there are other things that you'd like to see in the plugin.Right now everything finally runs smoothly here, and I'm quite happy with the plugin :D
In the long term a buckminster job type akin to the maven one would be awesome, of course. I've read the thread above about better integration with the SCM side of hudson and that definitely sounds great. Aside from that, the only thing I can think of that's missing compared to the maven stuff is automatic dependency tracking between jobs, i.e. if build job A has a query with component org.example.a as root request and build job B has a query with a dependency to org.example.a, then B could be automatically triggered when A was built successfully. In fact, when I find the time in a week or two, I might mess around a bit with hudson build triggers and see if I can come up with something like that...Best regards, Carsten
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? :) )
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?
Best regards, Johannes