Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 396816 - EPP hit by "No suitable provider" for sparcv9 bug
Summary: EPP hit by "No suitable provider" for sparcv9 bug
Status: CLOSED FIXED
Alias: None
Product: EPP
Classification: Technology
Component: Packager (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 1.4.0   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 396653
Blocks:
  Show dependency tree
 
Reported: 2012-12-18 05:11 EST by Markus Knauer CLA
Modified: 2013-12-18 13:58 EST (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Knauer CLA 2012-12-18 05:11:23 EST 
Of course, EPP is hit by the  "No suitable provider" for sparcv9 bug in Kepler M4, too.

     [java] WARN:  Target platform directory '/shared/technology/epp/epp_repo/kepler/epp.build/TP' does not exist and will be created

     [java] ERROR   [0002] : No suitable provider for component org.eclipse.core.filesystem.solaris.sparcv9:osgi.bundle(&(target.arch=sparcv9)(target.os=solaris)) was found in resourceMap file:/opt/public/technology/epp/epp_repo/kepler/git/features/org.eclipse.epp.allpackages.feature/epp.rmap
     [java]   ERROR   [0002] : No suitable provider for component org.eclipse.core.filesystem.solaris.sparcv9:osgi.bundle(&(target.arch=sparcv9)(target.os=solaris)) was found in searchPath simrelease
     [java]     ERROR   [0002] : Rejecting provider p2({0}?importType=binary[file:///home/data/httpd/download.eclipse.org/releases/staging?importType=binary]): No component match was found
Comment 1 Markus Knauer CLA 2012-12-18 05:29:55 EST 
Trying to try... the same workaround as Graphiti in 

* epp-tp.cquery and
* epp.cquery

Trying to try... I am not able to push to Git any more because of some SSH connection problems. :(
Comment 2 Markus Knauer CLA 2012-12-18 11:12:18 EST 
I had to adjust the build.xml file as well. In summary the following files have been changed:

* /org.eclipse.epp.allpackages.feature/build.xml
* /org.eclipse.epp.allpackages.feature/epp-tp.cquery and
* /org.eclipse.epp.allpackages.feature/epp.cquery

The architecture/OS is currently limited to the combinations that we need for the EPP build:

    <cq:property key="target.arch" value="x86,x86_64"/>
    <cq:property key="target.os" value="win32,linux,macosx"/>
Comment 3 Markus Knauer CLA 2012-12-20 08:00:52 EST 
I was running into a major problem: The generated metadata didn't contain any information about the changes in the eclipse.ini. Therefor I had to revert everything and chose to go another hacky way...

=> All changes in the EPP repository have been reverted.

=> I "solved" this problem now by

* making a copy of the simultaneous release repository 
  /releases/staging -> /technology/epp/staging
* adjusting the p2 metadata manully (i.e. remove 'sparcv9' references)
* healing the feature org.eclipse.platform_4.3.0.v20121210-194028-9PF7VHLnG0BBkXvb-5n61JdBeLn2Lmpr5BVxLP.jar (remove the non-existent dependency to the sparcv9 fragment, remove the signing information)
* update the p2 artifacts data  with the new md5 checksum of the feature

This modified copy of the staging repository is used by the Buckminster build part in order to generate the EPP features/bundles and the p2 metadata for the packages.

The packages itself were build using the normal /releases/staging repository without any modifications.
Comment 4 Markus Knauer CLA 2013-12-18 13:58:40 EST 
This was a temporary problem and is now resolved.
Closing the bug as fixed.