Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster dev » mspec problems with released buckminster
mspec problems with released buckminster [message #37715] Wed, 15 July 2009 07:54 Go to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi,

as discussed in
http://dev.eclipse.org/mhonarc/lists/buckminster-dev/msg0084 5.html I am
working on creating a tutorial on how to build eclipse RCPs with
buckminster and how to integrate that into a CI system (hudson in this
case).
The necessary modifications to the hudson plugin are in place and
deployed, but I'm having issues with materializing the target platform.
As suggested by Thomas I start by resolving a target platform with an mspec.
To do so I essentially use this mspec:
http://build.eclipse.org/tools/buckminster/hudson/tp.mspec
The only thing I had to modify was the tp.rmap because the URL wasn't
working anymore.
My modified rmap points to the galileo release:
<?xml version="1.0" encoding="UTF-8"?>
<rmap xmlns="http://www.eclipse.org/buckminster/RMap-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mp="http://www.eclipse.org/buckminster/MavenProvider-1.0"
xmlns:pmp="http://www.eclipse.org/buckminster/PDEMapProvider-1.0"
xmlns:bc="http://www.eclipse.org/buckminster/Common-1.0">

<searchPath name="org.eclipse.platform">
<provider readerType="eclipse.import"
componentTypes="osgi.bundle,eclipse.feature" mutable="false" source="false">
<uri
format=" http://download.eclipse.org/releases/galileo/?importType=bin ary"/>
</provider>
</searchPath>
<locator searchPathRef="org.eclipse.platform"/>
</rmap>

Apart from that, mspec, cspec and rmap are identical to the resources in
http://build.eclipse.org/tools/buckminster/hudson/

To start with the target platform I invoke buckminster like that:
java -DtargetPlatformPath=/where/target/platform/should/be/materi alized
-jar plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar
-application org.eclipse.buckminster.cmdline.headless
-data /data/directory/
--loglevel info
-S /commands.txt

The command to be executed in this case is simply
import http://url/to/tp.mspec

The path /where/target/platform/should/be/materialized does not exist
yet and should be populated with the freshly downloaded platform.
This works great with the RC4, but I get a bunch of error messages when
trying the released version. I verified this on two machines and it's
the same thing in both cases: RC4 works, released version does not.
The error messages are:
ERROR [0001] : An error occurred while collecting items to be installed
ERROR [0001] : session context
was:(profile=1247658332601-0.23645752893850414,
phase=org.eclipse.equinox.internal.provisional.p2.engine.pha ses.Collect,
operand=, action=).
ERROR [0001] : No repository found containing:
osgi.bundle,org.eclipse.equinox.common,3.5.0.v20090520-1800
ERROR [0001] : No repository found containing:
osgi.bundle,org.eclipse.equinox.registry,3.4.100.v20090520-1 800
ERROR [0001] : No repository found containing:
osgi.bundle,org.eclipse.core.runtime.compatibility.registry, 3.2.200.v20090429-1800

and many many more (A few hundred of those messages each with different
bundles. I'll attach the full trace as a file if requested). The funny
thing is though, resolving the cquery instead of importing the mspec
works just fine so those components obviously are in place and resolvable.

Any help here would be appreciated, because I can't really write a
tutorial that only works with a specific RC...

Best regards and thanks for the support,
Johannes
Re: mspec problems with released buckminster [message #37796 is a reply to message #37715] Wed, 15 July 2009 08:57 Go to previous messageGo to next message
Eclipse User
Originally posted by: creckord.uni-kassel.de

Hi Johannes,

I had the exact same problem, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=282810. Thomas fixed this in revision 10451, so a self-built
version of Buckminster should work.

An unrelated question: Currently the Hudson Buckminster builder does not show up in multi-configuration projects. Is this just a
configuration issue or are there additional requirements for a builder to support that?

Best regards,
Carsten

On 15.07.2009 13:54, Johannes Utzig wrote:
> Hi,
>
> as discussed in
> http://dev.eclipse.org/mhonarc/lists/buckminster-dev/msg0084 5.html I am
> working on creating a tutorial on how to build eclipse RCPs with
> buckminster and how to integrate that into a CI system (hudson in this
> case).
> The necessary modifications to the hudson plugin are in place and
> deployed, but I'm having issues with materializing the target platform.
> As suggested by Thomas I start by resolving a target platform with an mspec.
> To do so I essentially use this mspec:
> http://build.eclipse.org/tools/buckminster/hudson/tp.mspec
> The only thing I had to modify was the tp.rmap because the URL wasn't
> working anymore.
> My modified rmap points to the galileo release:
> <?xml version="1.0" encoding="UTF-8"?>
> <rmap xmlns="http://www.eclipse.org/buckminster/RMap-1.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:mp="http://www.eclipse.org/buckminster/MavenProvider-1.0"
> xmlns:pmp="http://www.eclipse.org/buckminster/PDEMapProvider-1.0"
> xmlns:bc="http://www.eclipse.org/buckminster/Common-1.0">
>
> <searchPath name="org.eclipse.platform">
> <provider readerType="eclipse.import"
> componentTypes="osgi.bundle,eclipse.feature" mutable="false" source="false">
> <uri
> format=" http://download.eclipse.org/releases/galileo/?importType=bin ary"/>
> </provider>
> </searchPath>
> <locator searchPathRef="org.eclipse.platform"/>
> </rmap>
>
> Apart from that, mspec, cspec and rmap are identical to the resources in
> http://build.eclipse.org/tools/buckminster/hudson/
>
> To start with the target platform I invoke buckminster like that:
> java -DtargetPlatformPath=/where/target/platform/should/be/materi alized
> -jar plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar
> -application org.eclipse.buckminster.cmdline.headless
> -data /data/directory/
> --loglevel info
> -S /commands.txt
>
> The command to be executed in this case is simply
> import http://url/to/tp.mspec
>
> The path /where/target/platform/should/be/materialized does not exist
> yet and should be populated with the freshly downloaded platform.
> This works great with the RC4, but I get a bunch of error messages when
> trying the released version. I verified this on two machines and it's
> the same thing in both cases: RC4 works, released version does not.
> The error messages are:
> ERROR [0001] : An error occurred while collecting items to be installed
> ERROR [0001] : session context
> was:(profile=1247658332601-0.23645752893850414,
> phase=org.eclipse.equinox.internal.provisional.p2.engine.pha ses.Collect,
> operand=, action=).
> ERROR [0001] : No repository found containing:
> osgi.bundle,org.eclipse.equinox.common,3.5.0.v20090520-1800
> ERROR [0001] : No repository found containing:
> osgi.bundle,org.eclipse.equinox.registry,3.4.100.v20090520-1 800
> ERROR [0001] : No repository found containing:
> osgi.bundle,org.eclipse.core.runtime.compatibility.registry, 3.2.200.v20090429-1800
>
> and many many more (A few hundred of those messages each with different
> bundles. I'll attach the full trace as a file if requested). The funny
> thing is though, resolving the cquery instead of importing the mspec
> works just fine so those components obviously are in place and resolvable.
>
> Any help here would be appreciated, because I can't really write a
> tutorial that only works with a specific RC...
>
> Best regards and thanks for the support,
> Johannes
Re: mspec problems with released buckminster [message #37829 is a reply to message #37796] Wed, 15 July 2009 09:11 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi Carsten,


thank you for your reply, looks like we have a habit of running into the
same bugs :)
Guess I'll need to wait for a new release then before actually
publishing anything.

Carsten Reckord schrieb:
> Hi Johannes,
>
> I had the exact same problem, see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=282810. Thomas fixed this
> in revision 10451, so a self-built version of Buckminster should work.
>
> An unrelated question: Currently the Hudson Buckminster builder does not
> show up in multi-configuration projects. Is this just a configuration
> issue or are there additional requirements for a builder to support that?
>

Well, this is quite easy to explain. In a builder you let hudson know
what kinds of jobs you are supporting and the builder will only be
visible in these projects. Since I only ever used the freestyle project
so far I did not add any support for other job types.
If that is an requirement of yours that can be arranged. Would you
please let me know more about your use-case and what you'd expect to
plugin to do?
Once I know the requirement better, I am quite positive that you can
have the support for matrix job types relativly soon.

From what I remember of reading about the matrix job, the builder will
be called several times with a new set of special matrix-properties each
time. Supporting that doesn't sound too difficult...


Best regards,
Johannes
Re: mspec problems with released buckminster [message #37863 is a reply to message #37829] Wed, 15 July 2009 12:49 Go to previous messageGo to next message
Eclipse User
Originally posted by: creckord.uni-kassel.de

This is a multi-part message in MIME format.
--------------000307090805000003020400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Johannes,

On 15.07.2009 15:11, Johannes Utzig wrote:
> Hi Carsten,
>
>
> thank you for your reply, looks like we have a habit of running into the
> same bugs :)
Looks like it :)

>> An unrelated question: Currently the Hudson Buckminster builder does not
>> show up in multi-configuration projects. Is this just a configuration
>> issue or are there additional requirements for a builder to support that?
>>
>
> Well, this is quite easy to explain. In a builder you let hudson know
> what kinds of jobs you are supporting and the builder will only be
> visible in these projects. Since I only ever used the freestyle project
> so far I did not add any support for other job types.
> If that is an requirement of yours that can be arranged. Would you
> please let me know more about your use-case and what you'd expect to
> plugin to do?
> Once I know the requirement better, I am quite positive that you can
> have the support for matrix job types relativly soon.
>
> From what I remember of reading about the matrix job, the builder will
> be called several times with a new set of special matrix-properties each
> time. Supporting that doesn't sound too difficult...

My use case is products for different platforms. We'd like to build products containing the platform-specific libraries and executable for a
set of platforms without including all the libraries for the other platforms, too. If I understood the matrix jobs correctly, the axes are
available as variables for the build steps and the job makes sure that the build is run for all valid combinations of axes. So basically
we'd like to do something like

axis os = win32 linux macosx
axis ws = win32 gtk cocoa carbon
axis arch = x86 x86_64
(bunch of combination filters)

bucky build step
resolve -D target.os=${os} -D target.ws=${ws} -D target.arch=${arch} our.mspec
perform -D target.os=${os} -D target.ws=${ws} -D target.arch=${arch} our.product.feature#create.product

Currently, we are using multiple projects for (a subset of) this, which is okay once it's set up, but it's gonna be a maintenance nightmare
come some changes to the build...

I've enabled the Buckminster builder for matrix projects in my local version and played around with it a bit. To get things running, the
EclipseBuckminsterBuilder needs to also use the variables from getBuildVars() for expansion. I've simply merged the two maps into one, don't
know if that's the right way to apply them, but it works nicely for me. I've attached a patch with my changes.

--------------000307090805000003020400
Content-Type: text/plain;
name="matrixsupport.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="matrixsupport.patch"

Index: buckminster/src/main/java/hudson/plugins/buckminster/Eclipse BuckminsterBuilder.java
============================================================ =======
--- buckminster/src/main/java/hudson/plugins/buckminster/Eclipse BuckminsterBuilder.java (revision 19726)
+++ buckminster/src/main/java/hudson/plugins/buckminster/Eclipse BuckminsterBuilder.java (working copy)
@@ -7,6 +7,7 @@
import hudson.model.BuildListener;
import hudson.model.Descriptor;
import hudson.model.FreeStyleProject;
+import hudson.matrix.MatrixProject;
import hudson.tasks.BuildStepDescriptor;
import hudson.tasks.Builder;
import hudson.util.FormValidation;
@@ -203,19 +204,24 @@
writer = new PrintWriter(new FileWriter(commandsPath));

String[] commands = getCommands().split("[\n\r]+");
- for (int i = 0; i < commands.length; i++) {
+
+ Map<String, String> properties = build.getEnvironment(listener);
+ Map<String, String> buildVars = build.getBuildVariables();
+ properties.putAll(buildVars);
+
+ for (int i = 0; i < commands.length; i++) {
if (!commands[i].startsWith("perform") || commands[i].startsWith("perform -D buckminster.output.root="))
// the command is not perform -> nothing to modify
//or
//the command is a perform, but with explicit output root
- writer.println(expandProperties(commands[i],build.getEnviron ment(listener)));
+ writer.println(expandProperties(commands[i], properties));
else {
// perform will usually produce build artifacts
// set the buckminster.output.root to the job's workspace
writer.print("perform -D buckminster.output.root=\""
+ build.getProject().getWorkspace().toURI().getPath()+"/buckminster.output\ "");
String commandAfterPerform = commands[i].replaceFirst("perform", "");
- commandAfterPerform = expandProperties(commandAfterPerform, build.getEnvironment(listener));
+ commandAfterPerform = expandProperties(commandAfterPerform, properties);
writer.println(commandAfterPerform);
// TODO: let the user set more properties

@@ -375,7 +381,7 @@

@Override
public boolean isApplicable(Class<? extends AbstractProject> jobType) {
- return FreeStyleProject.class.isAssignableFrom(jobType);
+ return FreeStyleProject.class.isAssignableFrom(jobType) || MatrixProject.class.isAssignableFrom(jobType);
}
}
}

--------------000307090805000003020400--
Re: mspec problems with released buckminster [message #37895 is a reply to message #37863] Wed, 15 July 2009 13:07 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi Carsten, see comments inline.

Carsten Reckord schrieb:
> Hi Johannes,
>
> On 15.07.2009 15:11, Johannes Utzig wrote:
>> Hi Carsten,
>>
>>
>> thank you for your reply, looks like we have a habit of running into
>> the same bugs :)
> Looks like it :)
>
>>> An unrelated question: Currently the Hudson Buckminster builder does
>>> not show up in multi-configuration projects. Is this just a
>>> configuration issue or are there additional requirements for a
>>> builder to support that?
>>>
>>
>> Well, this is quite easy to explain. In a builder you let hudson know
>> what kinds of jobs you are supporting and the builder will only be
>> visible in these projects. Since I only ever used the freestyle
>> project so far I did not add any support for other job types.
>> If that is an requirement of yours that can be arranged. Would you
>> please let me know more about your use-case and what you'd expect to
>> plugin to do?
>> Once I know the requirement better, I am quite positive that you can
>> have the support for matrix job types relativly soon.
>>
>> From what I remember of reading about the matrix job, the builder
>> will be called several times with a new set of special
>> matrix-properties each time. Supporting that doesn't sound too
>> difficult...
>
> My use case is products for different platforms. We'd like to build
> products containing the platform-specific libraries and executable for a
> set of platforms without including all the libraries for the other
> platforms, too. If I understood the matrix jobs correctly, the axes are
> available as variables for the build steps and the job makes sure that
> the build is run for all valid combinations of axes. So basically we'd
> like to do something like
>
> axis os = win32 linux macosx
> axis ws = win32 gtk cocoa carbon
> axis arch = x86 x86_64
> (bunch of combination filters)
>
I thought buckminster itself provider the means of building platform
agnostic
target.os=${*} ...
I must admit that it never quite worked for me but I think there's
something like that already implemented.
Apart from that, this requirement totally makes sense of course.

> bucky build step
> resolve -D target.os=${os} -D target.ws=${ws} -D target.arch=${arch}
> our.mspec
> perform -D target.os=${os} -D target.ws=${ws} -D target.arch=${arch}
> our.product.feature#create.product
>
> Currently, we are using multiple projects for (a subset of) this, which
> is okay once it's set up, but it's gonna be a maintenance nightmare come
> some changes to the build...
>
> I've enabled the Buckminster builder for matrix projects in my local
> version and played around with it a bit. To get things running, the
> EclipseBuckminsterBuilder needs to also use the variables from
> getBuildVars() for expansion. I've simply merged the two maps into one,
> don't know if that's the right way to apply them, but it works nicely
> for me. I've attached a patch with my changes.
>

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.
Please let me know when there are other things that you'd like to see in
the plugin.

Best regards,
Johannes
Re: mspec problems with released buckminster [message #37927 is a reply to message #37895] Wed, 15 July 2009 16:34 Go to previous messageGo to next message
Eclipse User
Originally posted by: creckord.uni-kassel.de

Hi Johannes,

On 15.07.2009 19:07, Johannes Utzig wrote:
> I thought buckminster itself provider the means of building platform
> agnostic
> target.os=${*} ...
> I must admit that it never quite worked for me but I think there's
> something like that already implemented.
Slight 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.

> 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
Re: mspec problems with released buckminster [message #38380 is a reply to message #37927] Fri, 17 July 2009 03:57 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Carsten Reckord schrieb:
> Hi Johannes,
>
> On 15.07.2009 19:07, Johannes Utzig wrote:
>> I thought buckminster itself provider the means of building platform
>> agnostic
>> target.os=${*} ...
>> I must admit that it never quite worked for me but I think there's
>> something like that already implemented.
> Slight 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.
>
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 :)

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

> 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
Re: mspec problems with released buckminster [message #38479 is a reply to message #38380] Fri, 17 July 2009 12:42 Go to previous messageGo to next message
Eclipse User
Originally posted by: creckord.uni-kassel.de

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

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

> 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?
Re: mspec problems with released buckminster [message #38743 is a reply to message #38479] Mon, 20 July 2009 04:30 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
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_hud son_(Buckminster)

Best regards,
Johannes
Re: mspec problems with released buckminster [message #38775 is a reply to message #38479] Thu, 23 July 2009 16:40 Go to previous message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi Carsten

Carsten Reckord schrieb:

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

Fixed with 0.8.4

Best regards,
Johannes
Previous Topic:[buckminster-dev] Automatic headless buckminster build and update
Next Topic:[buckminster-dev] download archive from cloudsmith?
Goto Forum:
  


Current Time: Thu Jul 24 13:54:37 EDT 2014

Powered by FUDForum. Page generated in 0.01853 seconds