[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] [Bug 339052] [environment] Optional lookup of EPackages in Registry by URI key
|
To shake a little bit more the cocktail, does anyone noticed the following
issue Bug 212120 ?. I've not spent any time in analyzing the proposed algorythm
to see if it could solve this problem, but anyway just a reminder for the
future ;)
Not sure I understand how this would impact the package lookup strategy.
Also, if the description at the beginning of that bug is supposed to be
a description of the as-is state, it may be off. It describes a top-down
lookup order, but actually given the context package, the lookup order
is inside-out.
The good news are that the patch doesn't change the present behaviour so I
think we are painless with it. Besides, it adds some useful
information/documentation concerning the delagating registry (which I didn't
know, BTW). +1
Ok, committed, with the following change:
Two minor comments:
- What about to include any kind of test to demonstrate the problem of looking
up packages using the global epackage registry as delegate ?
- What about if we avoid creating a delegating registry with the global
epackage registry ?. If it really doesn't work let's teach users to use in the
correct way. (testAliasPackageName and
testRegularPackageNameInContextWithAliasLookupEnabled tests).
I replaced the use of the delegating constructor by the default
constructor which is possible because the two tests don't depend on the
contents of the default registry.
Regarding demonstrating the problems of using the
(not-really-)delegating registry, did you have in mind to write a test
that unsuccessfully looks for a package through a "delegating" registry
which is only contained in the delegate?
Thanks and best,
-- Axel
Regards,
Adolfo.
