Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster » problems using b3aggregator & hudson with buckminster
problems using b3aggregator & hudson with buckminster [message #649997] Fri, 21 January 2011 11:33 Go to next message
David Gonzalez is currently offline David Gonzalez
Messages: 23
Registered: January 2011
Junior Member
Hey out there,

i've some problems using Hudson with Buckminster plugin and the b3 aggregator. I try to explain my concept (perhaps that's already the problem).

First of all we have some product here that depend on several components. There is for example one basic Component A (as a eclipse feature) that depends on some of our own plugins (and those plugins might have dependencies on eclipse plugins). Another Component B depends on some other plugins and on Component A. So the whole product depends on several Components (or eclipse features, however) and some plugins to put those Components together.

So idea was to let Hudson with Buckminster build those Components. That works fine as long as Buckminster gets all plugins/features from our SVN repo or the eclipse update sites. To minimize the traffic and to maximize the efficiency i want Buckminster now to get the dependency plugins/features from one (or later maybe more than one) local p2 repo. Only the "own" plugins of the feature should come from SVN to make sure the component uses the newest version of the plugins.

Well, so i started to use b3 aggregator and created a p2 from the eclipse p2 site and the p2 site our basic components create in Hudson. No problems so long.

After trying some other things i took a look in the workspace the jobs create and i just wondered how they could build the component because in this workspace was nearly nothing checked out from SVN (only the cquery and the rmap). I set the loglevel of Buckminster to 'Debug' and found out that Buckminster resolves the plugins from the target platform - and not from the aggregated repo or SVN. And i wonder why.

In my rmap i have 3 locators. The first one catches the plugins of the components that should be loaded from SVN, the second one catches all other of our plugins that are needed and the last one catches alle eclipse plugins. The last two should both get their plugins from the aggregated repo.

Maybe the problem is not the rmap, i could also be the target platform. Why are there my own plugins and not only the eclipse plugins i defined? I'm pretty sure that my own plugins where not part of the target platform in the beginning, so why does Buckminster (or Hudson?) put them to the target platform?

Lot of questions and perhaps it's not that complicated. I'm not really sure about some things, how they work and so on. If more information is needed (like the rmap or other things) then ask me, i just don't know what exactly is the problem.

Greets
Re: problems using b3aggregator & hudson with buckminster [message #650000 is a reply to message #649997] Fri, 21 January 2011 11:49 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi David,

Am 21.01.2011 12:33, schrieb david@gonzalez-casin.de:
> After trying some other things i took a look in the workspace the jobs
> create and i just wondered how they could build the component because in
> this workspace was nearly nothing checked out from SVN (only the cquery
> and the rmap). I set the loglevel of Buckminster to 'Debug' and found
> out that Buckminster resolves the plugins from the target platform - and
> not from the aggregated repo or SVN. And i wonder why.
> In my rmap i have 3 locators. The first one catches the plugins of the
> components that should be loaded from SVN, the second one catches all
> other of our plugins that are needed and the last one catches alle
> eclipse plugins. The last two should both get their plugins from the
> aggregated repo.

Obviously your SVN Locator (at one point) did not find the plugins in
question, so another reader was selected. This reader probably found the
bundles in your aggregated repository.
Since you probably did not define an MSPEC, the default behaviour if a
binary bundle is found is to stuff it into the target platform.
If you do not want the binary bundles from the aggregated repository to
end up in the target platform then you need an mspec to define this
behaviour.
After that you might have fixed the rmap so buckminster would in theory
be able to find the stuff in SVN, but:
It will not even try your rmap anymore since these bundle are already
installed in your target platform now.

There is two things you could do in such a case:
1. Create an advisor node in your query and do not allow the resolution
scope "Target Platform" for the bundles you want to download from the
aggregated Repo. That means however, that they have to be downloaded on
every build, which might, or might not be what you want

2. Make sure in your IDE that the locator that points to your SVN really
works as expected. Once you confirmed in an empty workspace that your
rmap finds everything from the right place, delete the target platform
in hudson and start over.


Best regards,
Johannes
Re: problems using b3aggregator & hudson with buckminster [message #650574 is a reply to message #649997] Tue, 25 January 2011 15:04 Go to previous messageGo to next message
David Gonzalez is currently offline David Gonzalez
Messages: 23
Registered: January 2011
Junior Member
Hi Johannes,

thank you!

I checked my SVN locator, it works fine. The problem is, as you said, that buckminster puts all materialized plugins to the target platform.

I followed your advice and added an advisor to my cquery. Works as expected and doesn't search in the target platform anymore. Smile

Well, finally i tried to create an MSPEC that refers my cquery but i don't understand what exactly to do there. I read the Bucky Book, Part II Chapter 8 about MSPEC. All i want to do is to materialize those plugins to the workspace of the job and NOT to materialize them to the target platform (seems to be the default behaviour without an MSPEC after materialization to the workspace?). Any suggestions to help me to get back on the track?

Greets
Re: problems using b3aggregator & hudson with buckminster [message #650602 is a reply to message #650574] Tue, 25 January 2011 17:01 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi again

Am 25.01.2011 16:04, schrieb Gonzo:
> Well, finally i tried to create an MSPEC that refers my cquery but i
> don't understand what exactly to do there. I read the Bucky Book, Part
> II Chapter 8 about MSPEC. All i want to do is to materialize those
> plugins to the workspace of the job and NOT to materialize them to the
> target platform (seems to be the default behaviour without an MSPEC
> after materialization to the workspace?). Any suggestions to help me to
> get back on the track?

Unfortunately I have not done this myself yet.
But from the description in the book I would expect that you have to
create a Materialization Node that matches the components you want to
redirect to the workspace, set it to use the workspace materializer and
leave location and workspace empty to use the defaults.

Best regards,
Johannes
Re: problems using b3aggregator & hudson with buckminster [message #651477 is a reply to message #649997] Mon, 31 January 2011 10:31 Go to previous messageGo to next message
David Gonzalez is currently offline David Gonzalez
Messages: 23
Registered: January 2011
Junior Member
Thank you, works fine for the moment!

Now I have another question. I use the following command to build my p2 site:

Quote:
perform -P '${WORKSPACE}com.example.releng/buckminster_p2site.propertie s' com.example.releng#site.p2


Works fine, but i want to have the output in a specified folder. In my .properties file I could set a property like this:

Quote:
buckminster.output.root=C:/test/


But then all the output goes there - I just want to have the output of the action #site.p2 there. Is there a possibility to do that? Otherwise I could move them with some shell commands via Hudson (but that doesn't sound like fun, I hope there is a better way to do that).

[Updated on: Mon, 31 January 2011 10:31]

Report message to a moderator

Re: problems using b3aggregator & hudson with buckminster [message #651486 is a reply to message #651477] Mon, 31 January 2011 10:55 Go to previous message
Johannes Utzig is currently offline Johannes Utzig
Messages: 329
Registered: July 2009
Senior Member
Hi again,

Am 31.01.2011 11:31, schrieb Gonzo:
> But then all the output goes there - I just want to have the output of
> the action #site.p2 there. Is there a possibility to do that? Otherwise
> I could move them with some shell commands via Hudson (but that doesn't
> sound like fun, I hope there is a better way to do that).

no, I do not think this is possible, sorry.
However, copying the specific artifact with a shell script shouldn't be
very challenging since the naming scheme is pretty self explaining.
You can also use hudson's 'archive artifacts' functionality to pick up
your artifacts with a simple regular expression like this:
buckminster.output/org.example.your.feature*/site.p2

Best regards,
Johannes
Previous Topic:Nested SVN tag resolution
Next Topic:site.p2 action does not generate all bundles correctly for create.product - SOLVED
Goto Forum:
  


Current Time: Thu Oct 30 12:58:33 GMT 2014

Powered by FUDForum. Page generated in 0.02345 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software