| Unpredictable resolution failures using remote PDE map files [message #381327] |
Wed, 26 November 2008 12:24  |
Eclipse User |
|
|
|
I've got an RMAP that has two searchPaths using PDE .map files
<searchPath name="my-stuff">
<provider readerType="eclipse.import" componentTypes="osgi.bundle"
mutable="false" source="false">
<uri
format="http://myHost/eclipse/updates/my-stuff/my-stuff.pluginmap" />
</provider>
</searchPath>
<searchPath name="orbit-stuff">
<provider readerType="eclipse.import" componentTypes="osgi.bundle"
mutable="false" source="false">
<uri
format=" http://myHost/eclipse/updates/orbit-stuff/orbit-stuff.plugin map" />
</provider>
</searchPath>
I see failures in resolution, randomly from one searchPath provider or the
other, for bundles referenced from the PDE map files.
I've done a build with maxParallelResolutions=1, but the resolutions still
fail with
the "No Suitable Provider for component x.y.z:osgi:bundle was found in
searchpath my-stuff"
message. On a manual check, x.y.z is in the .pluginmap file, and x.y.z.jar
is available using
a standard wget.
(I've renamed the .map files to .pluginmap, because for some reason the
map extension
makes the webserver spew. Could this be important?)
Before I go to the next step and dig into the code, has anyone seen this
kind
of behaviour before?
cheers
--oh
|
|
|
|
|
| Re: Unpredictable resolution failures using remote PDE map files [message #381340 is a reply to message #381330] |
Sun, 30 November 2008 18:23  |
| Eclipse User |
|
|
|
Thomas Hallgren wrote:
> Yes, most definitely. I'm surprised that your errors are random. The import
reader
> triggers on entries that ends with ".map". Only such entries are considered
to be maps so
> an extension of ".pluginmap" should fail completely. What errors do you see?
Could it be
> that the components are resolved using another provider/searchPath?
I neglected to reply to the newsgroup about this one - my apologies. The main
issue was the irregular file suffix. Once I had made sure that the PDE map
files were indeed .map, and web server had been prevented from trying to
interpret them as imagemaps, then resolution started to occur as expected :)
--oh
----
oisin hurley at iona
http://oisinh.wordpress.com
|
|
|
Powered by
FUDForum. Page generated in 0.29810 seconds
Home