When loading a bundle having a package that specifies a prerequisite
to another package in the bundle, the load can easily fail. This is due to code in Store which first will load the newest version of the prerequisite, then afterwards load the version actually specified in the bundle. Note that the prerequisite discussed here, is a "Development Prerequisite" specifying no version. Store is configured to "load latest" version of prerequisites (Store.Policies prerequisitePolicy versionSelection: #latest). I create a bundle 'Runar Store Test' with two packages that form the following structure: Runar Store Test Runar Store Test Gui Runar Store Test Domain "Runar Store Test Gui" has a prerequisite to "Runar Store Test Domain". I version all three pundles as 1.0. Then I modify "Runar Store Test Domain" and publish version 1.1 of this package only. The database then has this structure: Runar Store Test 1.0 Runar Store Test Gui 1.0 Runar Store Test Domain 1.0 1.1 With a base image I try to load Runar Store Test 1.0. Store will load the correct package versions after the entire bundle load has completed. All pundles are version 1.0. But… during load it will first load the wrong version (more specifically the "newest version", which is 1.1) of "Runar Store Test Domain". Finally, it loads version 1.0. Usually this is ok, but if you have made some types of changes in the newest package, the load fails. Reproducing a problem caused by this behaviour is harder, but thrust me -- it can be done. I got it when name spaces were changed between the versions. You could argue that Store simply does as it is told. First it obeys the prerequisite by loading "the newest version". Then as it progresses with the bundle load, it load the version specified in the actual bundle. Two loads -- just as told. I think that when loading packages from a parent bundle, the version in the bundle should be the only one loaded. There are two ways to avoid hitting this problem. Rearranging the order of the packages, would probably fix it. But it should not be necessary to fiddle with the order when you have proper prerequisites specified. Another option is to avoid using prerequisite all together. This is not a good solution if you want to give developers information on how various parts of a large system is composed. I use VisualWorks 7.4. Here is the stack trace leading up to loading the wrong version of 'Runar Store Test Domain': Store.Package(Store.Pundle)>>checkPundlePrerequisite:named:version: Arguments: reqType = #package reqName = 'Runar Store Test Domain' reqVersion = '' Temporaries: pundle = nil pundles = a SortedCollection[2] ---------------------------------------------------------------------- Store.Package(Store.Pundle)>>checkPrerequisite:name:version: Arguments: reqType = #package reqName = 'Runar Store Test Domain' reqVersion = '' Temporaries: pref = #parcelsFirst message = nil ---------------------------------------------------------------------- [] in Store.Package(Store.Pundle)>>checkPrerequisites Arguments: reqs = an Array[1] Temporaries: req = an Array[3] .self = {'Runar Store Test Gui'-'1.0'-482} ---------------------------------------------------------------------- Store.Package>>loadSrcWithin:warnReplace: Arguments: parentBundle = {'Runar Store Test'-'1.0'-281} warnReplace = false In Store.Package>>loadSrcWithin:warnReplace:, please note that parentBundle is one of the arguments. At this level the package actually knows it is being loaded as part of a bundle. But the next call (#checkPrerequisites) is not given this information. It goes on to #checkPrerequisite:name:version: and #checkPundlePrerequisite:named:version: not passing the information on the parent bundle. Maybe #checkPrerequisites could be changed to "checkPrerequisites: parentBundle" and then examine parentBundle to see if it contains prerequisites. If parentBundle does contain a prerequisite, the code would load the version specified in parentBundle. This solution is complicated by nested bundles, but should be solvable. Runar Jordahl |
Yes, I would say that the thing to do is to re-arrange the order of the packages within the bundle. Having a load order for something that is inconsistent with the prerequisites of the things that it contains is not a good idea. That being said, it's possible that some of the upcoming work on Store would render this moot, but I'm not sure about that.
At 06:41 PM 4/1/2006, Runar Jordahl wrote: >When loading a bundle having a package that specifies a prerequisite >to another package in the bundle, the load can easily fail. This is >due to code in Store which first will load the newest version of the >prerequisite, then afterwards load the version actually specified in >the bundle. > >Note that the prerequisite discussed here, is a "Development >Prerequisite" specifying no version. Store is configured to "load >latest" version of prerequisites (Store.Policies prerequisitePolicy >versionSelection: #latest). > >I create a bundle 'Runar Store Test' with two packages that form the >following structure: >Runar Store Test >Runar Store Test Gui >Runar Store Test Domain > >"Runar Store Test Gui" has a prerequisite to "Runar Store Test >Domain". I version all three pundles as 1.0. Then I modify "Runar >Store Test Domain" and publish version 1.1 of this package only. The >database then has this structure: > >Runar Store Test 1.0 >Runar Store Test Gui 1.0 >Runar Store Test Domain 1.0 1.1 > >With a base image I try to load Runar Store Test 1.0. > >Store will load the correct package versions after the entire bundle >load has completed. All pundles are version 1.0. ButÂ… during load it >will first load the wrong version (more specifically the "newest >version", which is 1.1) of "Runar Store Test Domain". Finally, it >loads version 1.0. Usually this is ok, but if you have made some types >of changes in the newest package, the load fails. Reproducing a >problem caused by this behaviour is harder, but thrust me -- it can be >done. I got it when name spaces were changed between the versions. > >You could argue that Store simply does as it is told. First it obeys >the prerequisite by loading "the newest version". Then as it >progresses with the bundle load, it load the version specified in the >actual bundle. Two loads -- just as told. I think that when loading >packages from a parent bundle, the version in the bundle should be the >only one loaded. > >There are two ways to avoid hitting this problem. Rearranging the >order of the packages, would probably fix it. But it should not be >necessary to fiddle with the order when you have proper prerequisites >specified. Another option is to avoid using prerequisite all together. >This is not a good solution if you want to give developers information >on how various parts of a large system is composed. > >I use VisualWorks 7.4. > >Here is the stack trace leading up to loading the wrong version of >'Runar Store Test Domain': > >Store.Package(Store.Pundle)>>checkPundlePrerequisite:named:version: >Arguments: > reqType = #package > reqName = 'Runar Store Test Domain' > reqVersion = '' >Temporaries: > pundle = nil > pundles = a SortedCollection[2] >---------------------------------------------------------------------- >Store.Package(Store.Pundle)>>checkPrerequisite:name:version: >Arguments: > reqType = #package > reqName = 'Runar Store Test Domain' > reqVersion = '' >Temporaries: > pref = #parcelsFirst > message = nil >---------------------------------------------------------------------- >[] in Store.Package(Store.Pundle)>>checkPrerequisites >Arguments: > reqs = an Array[1] >Temporaries: > req = an Array[3] > .self = {'Runar Store Test Gui'-'1.0'-482} >---------------------------------------------------------------------- >Store.Package>>loadSrcWithin:warnReplace: >Arguments: > parentBundle = {'Runar Store Test'-'1.0'-281} > warnReplace = false > > >In Store.Package>>loadSrcWithin:warnReplace:, please note that >parentBundle is one of the arguments. At this level the package >actually knows it is being loaded as part of a bundle. But the next >call (#checkPrerequisites) is not given this information. It goes on >to #checkPrerequisite:name:version: and >#checkPundlePrerequisite:named:version: not passing the information on >the parent bundle. > >Maybe #checkPrerequisites could be changed to "checkPrerequisites: >parentBundle" and then examine parentBundle to see if it contains >prerequisites. If parentBundle does contain a prerequisite, the code >would load the version specified in parentBundle. This solution is >complicated by nested bundles, but should be solvable. > >Runar Jordahl -- Alan Knight [|], Cincom Smalltalk Development [hidden email] [hidden email] http://www.cincom.com/smalltalk "The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross |
Free forum by Nabble | Edit this page |