Eclipse Community Forums: B3 » Merging two p2 repositories regardless of contents

Help

Home

Home » Archived » B3 » Merging two p2 repositories regardless of contents

Show: Today's Messages :: Show Polls :: Message Navigator

Merging two p2 repositories regardless of contents [message #682359]

Fri, 10 June 2011 23:12

Terran Gilman

Messages: 67
Registered: July 2009

Member

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.

Report message to a moderator

Re: Merging two p2 repositories regardless of contents [message #682467 is a reply to message #682359]

Sat, 11 June 2011 06:46

Thomas Hallgren

Messages: 3240
Registered: July 2009

Senior Member

Hi Trip,

The b3 aggregator is not a plain mirroring tool. It uses the planner to figure out how to create a coherent repository
that will not contain duplicates nor cause conflicts when used. These were very important requirements when the tool was
first created and used for assembling the Eclipse Galileo release.

The planner will run once for each configuration. If you have no configurations, then nothing will happen and no
mirroring will take place.

We are working on improvements that will enable "conflict resolution" by moving conflicting contributions into
"composite children". In essence this means that you can express several aggregations in the same model. The aggregator
will validate each one separately and thus still ensure some consistency in the result. See:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=338738

This is work in progress and the model may still undergo some changes but you are welcome to try it out from our interim
repositories at:

https://hudson.eclipse.org/hudson/job/emft-b3-build/ws/b3.p2.repository/
https://hudson.eclipse.org/hudson/job/emft-b3-build/ws/b3.headless.p2.repository/

We also have an enhancement request to allow plain mirroring:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=338409

HTH,
Thomas Hallgren

On 2011-06-11 01:12, Trip Gilman wrote:
> 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.

Report message to a moderator

Re: Merging two p2 repositories regardless of contents [message #683006 is a reply to message #682467]

Sun, 12 June 2011 19:40

Terran Gilman

Messages: 67
Registered: July 2009

Member

I think I understand the background of the aggregator better now, thank you. I have resolved the issue I was seeing earlier. It is actually a bug in buckminster that causes it to incorrectly add fragment bundles into the required section of its auto generated source features without including the proper platform filters.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=330088

I didn't really need the source features/bundles for my purpose so I disabled them to work around the issue.

I am now see a different error which may just be my trying to use b3 for something it's not really meant for. Let me provide a little more details on the what and why of my project.

I have an eclipse product that is being built using buckminster. This product and all its features are being published into a p2 repository via buckminster as well. I want to be able to place subsequent builds into the same repository, so that the repository will contain all released versions of the product as they are released (built). Buckminster does not support appending to an existing repository in its p2 site export, so they recommended I look into the b3 aggregator.

Here is the approach I've taken:

1) Build p2 site through buckminster
2) Build p2 site to secondary location (thus creating a new version via qualifiers)
3) Run b3 against these repositories to created merged repository

Here's an example of the error I am receiving:

Artifact org.eclipse.b3.p2.impl.ArtifactKeyImpl@75614662 (classifier: osgi.bundle, id: org.eclipse.vtp.framework.util, version: 3.0.26.201106121852) could not be found in the artifact repository (file:///_path_/site.p2)

The bundle is present in the artifacts.xml of the repository and the file is available in the bundles directory of the repository. Any ideas as to why this would be happening?

Report message to a moderator

Re: Merging two p2 repositories regardless of contents [message #683176 is a reply to message #683006]

Mon, 13 June 2011 06:09

Thomas Hallgren

Messages: 3240
Registered: July 2009

Senior Member

On 2011-06-12 21:40, Trip Gilman wrote:
> The bundle is present in the artifacts.xml of the repository and the file is available in the bundles directory of the
> repository. Any ideas as to why this would be happening?

No, not really. Do you have signing and/or pack200 involved? If so, will disabling it make any difference? Did you test
the integrity of the file? If the artifacts.xml has an checksum listed for the entry, then that checksum must match.

Regards,
Thomas Hallgren

Report message to a moderator

Re: Merging two p2 repositories regardless of contents [message #688380 is a reply to message #683176]

Fri, 24 June 2011 15:10

Terran Gilman

Messages: 67
Registered: July 2009

Member

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?

Report message to a moderator

Previous Topic:	example use of the p2 model in b3
Next Topic:	multiple versions of a feature could not be mirrored

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Mon Dec 04 10:11:08 GMT 2023

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter