| problems using b3aggregator & hudson with buckminster [message #649997] |
Fri, 21 January 2011 06:33  |
Eclipse User |
|
|
|
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 06:49  |
| Eclipse User |
|
|
|
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 #651486 is a reply to message #651477] |
Mon, 31 January 2011 05:55 |
| Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.05685 seconds
Home