[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] problems with resolve - uncaught exception
|
Todd_Lee@xxxxxxxx wrote:
Hi there,
Before I go and file a bug... This is a bit of a curiosity, but I certainly wouldn't rule out the fact
that I could be doing something wrong with my rmap :)
I'm sure this is a bug in the new extended resolver decision logging. Please file this in the bugzilla.
What is the recommended method for resolving where you're using PDE maps
with cvs readers in the case where you may have multiple cvs paths to
contend with?
eg:
We might have dependencies to resolve like the following:
/path/to/cvs/moduleA/root/buckminster.component
/path/to/cvs/moduleB/root/buckminster.component
is it best to try a match/replace with properties? Or can we use multiple
cvs providers in a search path to coordinate with the PDE map provider?
A PDE map can have multiple entries pointing all over the place. One single map may even appoint
completely different CVS repositories using different protocols. The important thing is to find the
map. From there on, it will build it's internal catalog of component mappings and delegate using
that. So my recommendation would be to use one map folder and put all maps there. Point to that map
folder with a PDEMapProvider and you're all set.
Perhaps your set-up already contain several different map folders? If that's the case, then you can
do one of two things:
1. If it is possible to select the map folder to use from some characteristic of the component name,
then you should use several search paths, one for each map folder that you want to find. Create
locator entries that will cause the resolver to choose the correct search path based on the
component name.
2. If component names have no characteristic that will help you do #1, then create one search path
and add several map providers to that search path. One for each map folder. Order the providers so
that the most commonly used map folder is placed first. The resolver will use all the map folders,
one at a time, to try and resolve the request.
#2 is slightly slower since the scope for the resolution becomes less focused at the end. Given the
nature of the map provider I don't think it will matter that much. Once all maps are read into
memory, it's just hashmap lookups anyway.
Regards,
Thomas Hallgren
