| Merging two p2 repositories regardless of contents [message #682359] |
Fri, 10 June 2011 19:12  |
Eclipse User |
|
|
|
I have two p2 repositories that I am trying to merge together. I really don't care to do any sort of platform based validation of the results. I just want to blindly merge what's there.
The problem that I'm running into is that at least one configuration element is required. When I add one in I receive an error during validation:
Cannot complete the install because one or more required items could not be found.
Software being installed: all.contributed.content.feature.group 1.0.0
Missing requirement: Source for Base Platform Feature 4.0.0.201106102259 (com.openmethods.ep.features.base.blank.source.feature.group 4.0.0.201106102259) requires 'com.openmethods.ep.win32.x86 [4.0.0.201106102259]' but it could not be found
Cannot satisfy dependency:
From: all.contributed.content.feature.group 1.0.0
To: com.openmethods.ep.features.base.blank.source.feature.group 0.0.0
The configuration is only for macosx at the moment. All features that reference these fragments have the correct platform filters applied and the fragment bundles themselves have the proper filters applied as well.
If I disable the configuration, the validation passes, but the resulting repository is empty. Is there something wrong with the way platform specific fragments are being handled, or am I doing something incorrectly?
Any help would be appreciated.
|
|
|
|
|
|
| Re: Merging two p2 repositories regardless of contents [message #688380 is a reply to message #683176] |
Fri, 24 June 2011 11:10  |
| Eclipse User |
|
|
|
There were two things at work here. First, Buckminster was not honoring the "no binary launcher included" directive of our product and including the one related to the system being built on. This would not have been a problem, except Buckminster also is failing to replace the version qualifier for the binary launcher as it does for all the plugins and features. This caused an issue as the binary file in each repository had the same version but differing md5 hashes.
The second contributor to the issue was based on using buckminster through the IDE and having some directory based plugins in our target platform. These folders were being re-jarred as part of the p2.site action, generating the same version number but differing md5 hashes.
To solve these issues we have done the following:
* We no longer utilize a .product file
* We now maintain 2 feature sets, one for generating the install repository that includes all of the target platform and a second one that is used to generate the p2 site to be used for updating that only includes our code
The problem is that even though the aggregator runs without errors, it still does not do what we need. It takes two p2 sites that contain different versions of our software, and creates a new p2 site with just the latest version of that software. The sole reason for inserting b3 into our tool chain was to take two repositories like these and create a third that contains version 1 and version 2 of the same code and put them into a new repository.
Is this behavior possible using b3?
|
|
|
Powered by
FUDForum. Page generated in 0.08473 seconds
Home