Moved: Dependency satisfaction with different bundle versions [message #903563] |
Fri, 24 August 2012 11:03 |
Kevin Milburn Messages: 13 Registered: July 2012 |
Junior Member |
|
|
I'm trying integrate some features into and RCP application and have hit a dependency issue with my target platform.
Cannot resolve project dependencies:
Software being installed: org.apache.xerces 2.11.0
Only one of the following can be installed at once: [org.apache.xerces 2.11.0, org.apache.xerces 2.9.0]
Cannot satisfy dependency: org.eclipse.wst.xml_core.feature.feature.group 3.4.0 depends on: org.apache.xerces [2.9.0]
How can I get around this problem?
[Updated on: Fri, 31 August 2012 10:39] Report message to a moderator
|
|
|
|
Re: Dependency satisfaction with different bundle versions [message #904476 is a reply to message #904434] |
Tue, 28 August 2012 13:45 |
Kevin Milburn Messages: 13 Registered: July 2012 |
Junior Member |
|
|
I have a target platform definition, which looks something like this:
<target name="eclipse 4.2 (juno)" sequenceNumber="2">
<locations>
<location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
<unit id="org.apache.xerces" version="2.11.0"/>
<repository location="localserver/repository/"/>
</location>
<location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
...
<unit id="org.eclipse.wst.xml_xml_core.feature.feature.group" version="3.4.0.v201111021744-7C7OFm4F7RZHQRIpOz-P2Xk"/>
<repository location="eclipse/releases/juno"/>
</location>
</locations>
</target>
When loading the file in the Target Editor, I get the above 'Cannot resolve project dependencies' messages, which prevents it's use as the active target.
From what I gather, the problem is that the wst.xml_core feature specifies org.apache.xerces 2.9.0 as an included plugin, and I'm trying to include version 2.11.0 of the same plugin.
When the platform is being resolved, somthing within p2 is deciding that it cannot have both 2.9.0 and 2.11.0 of the same plugin, and because it wants to install 2.11.0 it cannot satify the dependency for 2.9.0.
In this instance, I could repackage the plugin with a different name and all would be well (including the existences of differing versions of the same packages), however, this seems like a arbitrary workaround to a problem that shouldn't exist.
And what would I do if I was including different features I was not in control of which results in the same problem.
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02993 seconds