|
| Re: Materializing binary feature in the workspace [message #550371 is a reply to message #550176] |
Fri, 30 July 2010 06:44   |
|
Hi Peter,
Reusing target platforms is, as you just found out, not ideal. I think
the main reason why it takes a long time to rebuild a new TP is that you
use a remote p2 repository. So why not use a local one? You can
streamline a p2 repository to contain exactly what's needed using the b3
aggregator and then use that when you provision the TP.
All in all, I think repositories are ideal for this kind of scenarios
where one build produces things that another build consumes. The result
of the second build can be a composite that contains the result of both
builds, etc. Each build consumes source and p2 repositories and creates
new p2 repositories.
Importing binaries into the workspace from a remote location has always
been a bit of a hack and my preference would be to get rid of it
altogether rather then spending time making it work for all types of
binaries. A patch would of course be accepted should you want to spend
time on fixing it. If so, please open a bugzilla.
- thomas
On 07/29/2010 02:32 PM, Peter Kullmann wrote:
> I have problems materializing binary features into the workspace. The
> error I get is:
>
> ERROR [0003] : IU
> ch.arenae.dnp.data.feature.feature.group/2.0.0.N20100729-1 has no artifacts
>
> It works fine if the feature is materialized into the target platform
> (with the p2 materializer). But I want to have it in the workspace. I'm
> not quite sure, but I think this was possible with the 3.5 code.
>
>
> Here is some background to explain why I would like to materialize this
> binary feature in the workspace: We have an rcp application consisting
> of two components A and B where B depends on A. We have set up a hudson
> build for A and I now want to build B. For B I would like to take a
> pre-compiled and tested version of A. B has also other dependencies like
> org.eclipse.swt and so on. So I have a target definition (a .target
> file) that specifies the target components. The target definition
> consists only of p2 sites so that it can easily be shared among our
> developers.
>
> How to build B (with buckminster headless)?
> 1st approach: Take a new workspace, import the target definition and set
> it active. Then import the B component. The source plugins of B will be
> in the workspace and the binary dependencies are meterialized using the
> p2 materializer into the target platform. BUT: The target platform
> (consisting of p2 site references) cannot (apparently) take the new
> binary components. Therefore, buckminster creates a new target platform,
> materializes the binaries from A and sets this new target active.
> Naturally, nothing will compile in this setting.
>
> 2nd approach: Like the first approach but use an mspec that directs the
> binaries from A into the workspace. This is what I would like to do.
>
> 3rd approach: Use a buckminster cspec or a feature to describe the
> target (instead of a .target file). Start with a new workspace, create
> an empty target (or use the buckminster default target) and materialize
> the target cspec or feature. After that materialize B (and with it A)
> which will probably work. The problem of this approach is that it takes
> a long time. I would like to reuse the target with the buckminster
> hudson plugin.
>
> Regards
> Peter
|
|
|
| Re: Materializing binary feature in the workspace [message #550660 is a reply to message #550371] |
Wed, 04 August 2010 05:19 |
 Peter Kullmann
Messages: 240
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas
Thanks for your explanation. That was very helpful. I changed my build
to this scheme and am quite happy with it.
Peter
Thomas Hallgren schrieb:
> Hi Peter,
>
> Reusing target platforms is, as you just found out, not ideal. I think
> the main reason why it takes a long time to rebuild a new TP is that you
> use a remote p2 repository. So why not use a local one? You can
> streamline a p2 repository to contain exactly what's needed using the b3
> aggregator and then use that when you provision the TP.
>
> All in all, I think repositories are ideal for this kind of scenarios
> where one build produces things that another build consumes. The result
> of the second build can be a composite that contains the result of both
> builds, etc. Each build consumes source and p2 repositories and creates
> new p2 repositories.
>
> Importing binaries into the workspace from a remote location has always
> been a bit of a hack and my preference would be to get rid of it
> altogether rather then spending time making it work for all types of
> binaries. A patch would of course be accepted should you want to spend
> time on fixing it. If so, please open a bugzilla.
>
> - thomas
>
>
>
> On 07/29/2010 02:32 PM, Peter Kullmann wrote:
>> I have problems materializing binary features into the workspace. The
>> error I get is:
>>
>> ERROR [0003] : IU
>> ch.arenae.dnp.data.feature.feature.group/2.0.0.N20100729-1 has no
>> artifacts
>>
>> It works fine if the feature is materialized into the target platform
>> (with the p2 materializer). But I want to have it in the workspace. I'm
>> not quite sure, but I think this was possible with the 3.5 code.
>>
>>
>> Here is some background to explain why I would like to materialize this
>> binary feature in the workspace: We have an rcp application consisting
>> of two components A and B where B depends on A. We have set up a hudson
>> build for A and I now want to build B. For B I would like to take a
>> pre-compiled and tested version of A. B has also other dependencies like
>> org.eclipse.swt and so on. So I have a target definition (a .target
>> file) that specifies the target components. The target definition
>> consists only of p2 sites so that it can easily be shared among our
>> developers.
>>
>> How to build B (with buckminster headless)?
>> 1st approach: Take a new workspace, import the target definition and set
>> it active. Then import the B component. The source plugins of B will be
>> in the workspace and the binary dependencies are meterialized using the
>> p2 materializer into the target platform. BUT: The target platform
>> (consisting of p2 site references) cannot (apparently) take the new
>> binary components. Therefore, buckminster creates a new target platform,
>> materializes the binaries from A and sets this new target active.
>> Naturally, nothing will compile in this setting.
>>
>> 2nd approach: Like the first approach but use an mspec that directs the
>> binaries from A into the workspace. This is what I would like to do.
>>
>> 3rd approach: Use a buckminster cspec or a feature to describe the
>> target (instead of a .target file). Start with a new workspace, create
>> an empty target (or use the buckminster default target) and materialize
>> the target cspec or feature. After that materialize B (and with it A)
>> which will probably work. The problem of this approach is that it takes
>> a long time. I would like to reuse the target with the buckminster
>> hudson plugin.
>>
>> Regards
>> Peter
>
|
|
|
Powered by
FUDForum. Page generated in 0.02671 seconds
] 
Search
Help
Register
Login
Home
