[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Hudson plugin and provisioning
|
Hi Johannes,
On 03/23/2010 06:34 PM, Johannes Utzig wrote:
Hi Thomas,
it was a choice made relatively early. It derives from the way I'm using
Buckminster in a CI environment. Developers and Hudson use the same RMAP
and I always want hudson to do the checkout because of the change log,
the update in favor of checkout and possibly automatically triggered
builds on SCM changes:
<searchPath name="mystuff">
<provider readerType="local"
componentTypes="osgi.bundle,eclipse.feature" mutable="true" source="true">
<uri format="file:///{0}/{1}/">
<bc:propertyRef key="workspace.root" />
<bc:propertyRef key="buckminster.component" />
</uri>
</provider>
<provider readerType="cvs"
componentTypes="eclipse.feature,osgi.bundle,buckminster,site.feature"
source="true">
<uri
format=":extssh:{0}@myserver:22/cvsroot/,module/{1}">
<bc:propertyRef key="user.name" />
<bc:propertyRef key="buckminster.component" />
</uri>
</provider>
</searchPath>
That way everything has the same layout like in my eclipse workspace and
it enables buckminster to easily find everything that hudson checked out.
I can understand that. It's the same scenario that I use for git. But the physical location of the checked out material
doesn't need to be the same as the physical location of the workspace root and Buckminster needs to bind things to a
workspace anyway so it doesn't really matter where things are as long as you can keep things from colliding.
If you prefer an eclipse workspace inside of a hudson workspace
scenario, how about an additional setting in the advanced section of the
build step configuration that lets you configure a nested workspace?
output and temp default to 'buckminster.output' and 'buckminster.temp'
in the workspace root, so that's similar enough I guess.
That would be an elegant solution.
- thomas
