----- "Mariano Martinez Peck" <[email protected]> wrote:
| > The nesting level for '1.1.3 [ConfigurationOfOmniBrowser]' and '1.1
| > [ConfigurationOfAutomaticMethodCategorizer]' are the same which
| means that
| > they are both referenced in '1.1 [ConfigurationOfPharo]'. That was
| enough to
| > solve this particular problem, but in an Inspector, you can dive
| into the
| > directives themselves and actually get to the MetacelloSpec that was
| used to
| > create the directive...
| >
| >
| >
| Here is what I don't understand. If you have that directive, and you
| have
| ALL that information, can't you guess that if you need to load the N
| version
| of a package and then the version M, where M > N, then you can skip to
| load
| N and just load M directly ?
|
| In this example, can you DO NOT load OmniBrowser-lr.458 as you know
| that
| after you will load OmniBrowser-lr.469 ?
| Or maybe directly about conf: Do not load 1.1
| [ConfigurationOfOmniBrowser] if you know that then you will need to
| load
| 1.1.3 [ConfigurationOfOmniBrowser]
Mariano,
If you were using #atomic loads then what you are suggesting would happen ...
Metacello would recognize that OmniBrowser-lr.469 was later and would use that
instead of the older mcz file.
With #linear loads it isn't necessarily safe to substitute a newer version of
an mcz file earlier into the load sequence, because the newer version may have
dependencies that wouldn't necessarily be satisfied this early in the load
sequence...The only safe way is to explicitly move the project earlier in the
sequence.
Moving the specification of OmniBrowser before the spec for
AutomaticMethodCategorizer does result in the correct mcz file for OB-Standard
to be loaded, however, other issues are exposed:
SHOUT uses the deprecated registerMenu API
Refactoring Browser needs to be moved earlier to avoid double
loading. I didn't notice any ill effects of loading earlier version of
Refactoring Browser.
Nile-Clients-MarianoMartinezPeck.178 has an issue with #isInMemory not
understood
Perhaps the MNU is due to the fact that I haven't updated
PharoCore-1.1-11326-UNSTABLE.
My tests to this point were done with Metacello 1.0-beta.26.1 (in development)
to eliminate any (known) Metacello bugs from the equation.
At this point I don't think 1.0-beta.26.1 is needed, but I will run an
additional test and let you know...
Dale
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
