It’s raining Metacello load problems today… well, actually mine is a MetacelloPreview issue with a twist ;-)
And I might have found what’s wrong with this one so I want to check on what to do next… - In a standard GLASS-1.0-beta.9 (GS 3.1), with MyProject loaded, I upgraded to the MetacelloPreview. - The ConfigurationOfMyProject references GLASS 1.0-beta.9 as a prerequisite. - I load an updated #development version of MyProject using the MetacelloPreview scripting API and I am denying all project upgrades/downgrades/conflicts - Everything works as expected but a subsequent (identical) load of ConfigurationOfMyProject will fail as follows: --transcript--'DENIED: a MetacelloAllowProjectDowngrade occurred (notification 2741) Metacello (1.0-beta.32.1)->Metacello (1.0-beta.32)' --transcript--'Project: Metacello Tools 1.0-beta.32' ERROR 2318 , a UserDefinedError occurred (error 2318), reason:halt, Name not found: OB-Metacello (UserDefinedError) What (I think) happens here is this: - The Metacello registry says ConfigurationOfMetacello is 1.0-beta.32.1 from http://seaside.gemstone.com/ss/metacello (only after the first load with the MetacelloPreview!) - The ConfigurationOfMyProject references GLASS 1.0-beta.9 which references the package ‘OB-Metacello’ in Metacello 1.0-beta.32 - The (loaded) version 1.0-beta.32.1, however, does not have the package ‘OB-Metacello’ in its spec. - Because I deny all upgrades/downgrades, the loading still tries to find ‘OB-Metacello’ in the 1.0-beta.32.1 version of Metacello I have two solutions: - not reference GLASS in ConfigurationOfMyProject until it references the latest Metacello (or MetacelloPreview) - not use MetacelloPreview (If I revert to using Metacello 1.0-beta.32 and I erase the registry, it works again) I also noticed that if I load my project in a clean image using the MetacelloPreview, many more configurations and packages are being loaded than using the ‘standard’ Metacello. I do all loads using the Metacello scripting api. Could it be that MetacelloPreview goes on walking the referenced projects even if you deny an upgrade? I have that impression… but I will try to demonstrate it more. Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Yeah, the good side of this is I haven't really changed Metacello Preview in maybe 6 months or more (definitely not in the last couple of months), so the flood of problems means folks are finally using it:) Your analysis of the deny upgrade/downgrades sounds correct ... I _would_ like to know the value of #loads instance variable for the configurationProjectSpec in the project registration for Metacello (poke around in the `MetacelloProjectRegistration registry` to find the project registration) ...
Well, the next change I was planning to make to ConfigurationofGLASS was to point it at th egithub glassdb repo ... what does that do to your plans? I would like to see the two transcripts to get a better idea of what you are referring to ...
Dale On Tue, Jun 10, 2014 at 2:45 PM, Johan Brichau <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Johan Brichau-3
So Johan, this reference to OB-Metacello is basically a configuration error ... it is no longer valid to reference the package OB-Metacello from GLASS once you have loaded a newer version of Metacello into the image that no longer manages OB-Metacello ... and I think that all that is necessary is that 'Metacello Tools' be removed from the 'Dev' group and 'Bob should be your uncle' ...
Is there a reason that you are using GLASS 1.0-beta.9? I would be inclined to create a 1.0-beta.9.2 with this change ... but you'd probably need to upgrade ... the alternative to that would be to create a 1.0-beta.9.0.1 (??) that has this change ...
BTW, I think I've seen your "many more configurations and packages are being loaded" and I'm looking into it ... Dale On Tue, Jun 10, 2014 at 2:45 PM, Johan Brichau <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Thanks Dale.
I already feared there was not so much to do about this one (in general, that is). As you say: it *is* an invalid reference but I fear it’s a nasty problem that will pop up more and more in the context of locked projects and evolving configurations. Seaside has this problem as well. The scenario is similar: - I have locked my images to Seaside 3.0.10 and I am loading the newest version of the ConfigurationOfSeaside3 to upgrade to Seaside 3.0.13 - Other configurations reference Seaside #stable version with a group that is defined for Seaside 3.1.x but not for Seaside 3.0.x - The load breaks with a ‘name not found’ because I have locked Seaside to 3.0.10 and the configuration that references #stable references a name in the 3.1.x version of Seaside I don’t see how I would want these things solved either, except maybe that Metacello would ignore such errors in the presence of locked versions (since I am not going to load the new referenced version anyway). But I guess that would not be the whole story… and is probably more than a tough nut to crack... In the end, the problem is evolution of configurations and the resulting incompatibilities :-( cheers Johan On 21 Jun 2014, at 04:34, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Dale Henrichs-3
On 21 Jun 2014, at 04:34, Dale Henrichs <[hidden email]> wrote: Is there a reason that you are using GLASS 1.0-beta.9? I would be inclined to create a 1.0-beta.9.2 with this change ... but you'd probably need to upgrade ... the alternative to that would be to create a 1.0-beta.9.0.1 (??) that has this change ... Forgot to answer on this one. It’s just because I did not notice there was a 9.1 ;-) I am planning to upgrade to the latest GLASS version. So, a 9.2 is perfect. Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
I think that the Seaside approach of using version-based symbolic versions (like #release31) is the proper approach, but that practice isn't applied consistently across all projects that use Seaside ...
today #stable works because #stable refers to Seaside3.9 ... tomorrow #stable doesn't work because the #stable suddenly refers to Seaside3.1 ... If the goal is for Seaside3.0 and Seaside3.1 to be used interchangeable from external proejcts, then perhaps some care needs to be taken to resolve some of these incompatibilities ... if a package has been remove then perhaps a group that routes references to the new package (or packages) is called for to allow older project configurations to continue to function...
Configurations are no different than software ... there is no magic ... there is a "project api" contract that you make with older versions that must be carried forward as the product evolves IF you want folks to be able to use things interchangeably ...
Dale On Sat, Jun 21, 2014 at 3:00 AM, Johan Brichau <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
> On 21 Jun 2014, at 15:23, Dale Henrichs <[hidden email]> wrote: > > I think that the Seaside approach of using version-based symbolic versions (like #release31) is the proper approach, but that practice isn't applied consistently across all projects that use Seaside ... Yes. We must actively promote that and it's the only solution to this evolution problem. Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
I've found it very difficult to communicate these things to the community at large ... besides folks are always busy getting the latest version working on the latest version of Pharo and little attention is paid to keeping existing versions running smoothly... I have resorted to "configuration gardening" where I go around and weed other peoples gardens and correct the "configuration problems" at the source:) Dale
On Sat, Jun 21, 2014 at 6:28 AM, Johan Brichau <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by Dale Henrichs-3
On Saturday, June 21, 2014 4:34:17 AM UTC+2, Dale wrote:
I found out why this was happening in my case. In a fresh 3.1.0.6 image, the Metacello registry has version 0.231 (or something) registered as the load GLASS, although 1.0-beta.9 is loaded. Since my ConfigurationOf references GLASS 1.0-beta.9, a load conflict occurred and it seems Metacello went down the path of fetching all configurations needed for GLASS 0.231. It starts with ConfigurationOfGsSeaside28 and then the entire referenced enchillada gets fetched. When I remove that entry from the registry, the conflict does not occur and my load is 'fine'. I guess the registry entry is erroneous, no? _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
yes that is suspicious ... so I've been fixing registry bugs at a hefty clip and the new stuff seems to be correct ... I've been hammering on the registry pretty hard with tODE and I've fixed several rigistry related issues ... there was definitely a period where the registry was getting corrupted by a normal Metacello load so it probably is related to haveing older versions of Metacello loaded as well ... Since I'm not ablte to reproduce the problem yet, I'm inclined to to publish a "fixed" 1.0-beta9.2 and let you take it for a spin...
On Mon, Jun 23, 2014 at 3:05 PM, Johan Brichau <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Dale,
A fresh download of a 3.1.0.6 has the metacello registry for GLASS set at version 0.231. I tried now with the most recent master of MetacelloPreview and I get the same behavior. I have the impression the metacello registry for a fresh downloaded image should just reference 1.0-beta.9 for GLASS (which is the one that comes installed)? Not really breaking for me, because I can easily solve this by removing the registry entry before doing a first load in a fresh extent. But I guess others might hit this too. thx Johan On 24 Jun 2014, at 00:13, Dale Henrichs <[hidden email]> wrote: > yes that is suspicious ... so I've been fixing registry bugs at a hefty clip and the new stuff seems to be correct ... I've been hammering on the registry pretty hard with tODE and I've fixed several rigistry related issues ... there was definitely a period where the registry was getting corrupted by a normal Metacello load so it probably is related to haveing older versions of Metacello loaded as well ... Since I'm not ablte to reproduce the problem yet, I'm inclined to to publish a "fixed" 1.0-beta9.2 and let you take it for a spin... > > > On Mon, Jun 23, 2014 at 3:05 PM, Johan Brichau <[hidden email]> wrote: > > > On Saturday, June 21, 2014 4:34:17 AM UTC+2, Dale wrote: > > BTW, I think I've seen your "many more configurations and packages are being loaded" and I'm looking into it ... > > I found out why this was happening in my case. > In a fresh 3.1.0.6 image, the Metacello registry has version 0.231 (or something) registered as the load GLASS, although 1.0-beta.9 is loaded. > > Since my ConfigurationOf references GLASS 1.0-beta.9, a load conflict occurred and it seems Metacello went down the path of fetching all configurations needed for GLASS 0.231. It starts with ConfigurationOfGsSeaside28 and then the entire referenced enchillada gets fetched. > > When I remove that entry from the registry, the conflict does not occur and my load is 'fine'. > > I guess the registry entry is erroneous, no? > > -- > You received this message because you are subscribed to the Google Groups "Metacello" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups "Metacello" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/d/optout. _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
How do you get things to break in 3.1.0.6? On Tue, Jun 24, 2014 at 12:19 AM, Johan Brichau <[hidden email]> wrote: Dale, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 24 Jun 2014, at 16:08, Dale Henrichs <[hidden email]> wrote: > How do you get things to break in 3.1.0.6? I created a small ConfigurationOfTest with the following baseline in a freshly download 3.1.0.6 extent. baseline: spec <version: '1.0-baseline'> spec for: #common do:[ spec project: 'GLASS' with: [ spec className: 'ConfigurationOfGLASS'; versionString: '1.0-beta.9.2'; repository: 'http://seaside.gemtalksystems.com/ss/MetacelloRepository']. spec project: 'Seaside30' with: [ spec className: 'ConfigurationOfSeaside3'; versionString: '3.0.13'; loads: #('Core'); repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main']. spec group: 'default' with: #('GLASS' 'Seaside30')] Next, I execute this in topaz: "Load the MetacelloPreview bleeding edge master" (Smalltalk at: #Metacello) new baseline: 'Metacello'; repository: 'github://dalehenrich/metacello-work:master/repository'; load. "Load Seaside 3.0.13" Metacello new configuration: 'Seaside3'; repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main'; version: '3.0.13'; load. "Load My project, prevent upgrades of referenced projects" Metacello new configuration: 'Test'; version: '1.0-baseline'; onConflict:[:ex | Transcript show: 'CONFLICT: ',ex description, ' ', ex existingProjectRegistration baseName,' (',ex existingProjectRegistration version,')->', ex newProjectRegistration baseName,' (',ex newProjectRegistration version,')'. ex disallow.]; onUpgrade: [:ex | Transcript show: 'UPGRADE: ',ex description, ' ', ex existingProjectRegistration baseName,' (',ex existingProjectRegistration version,')->', ex newProjectRegistration baseName,' (',ex newProjectRegistration version,')'. ex disallow. ]; load The last load expression breaks as follows: --transcript--'Loading 1.0-baseline of ConfigurationOfTest...' --transcript--'UPGRADE: a MetacelloAllowProjectUpgrade occurred (notification 2741) GLASS (0.231)->GLASS (1.0-beta.9.2)' --transcript--'...RETRY->ConfigurationOfGLASS' --transcript--'...RETRY->ConfigurationOfGLASS' --transcript--'...FAILED->ConfigurationOfGLASS' ERROR 2710 , a MetacelloPackageSpecResolutionError occurred (error 2710) (MetacelloPackageSpecResolutionError) This is a little different from what I see in my case but I believe it boils down to the same problem: Because the registry still points to GLASS 0.231, a conflict occurs and Metacello starts fetching that version. In the example I mention in this email it breaks because the repository of that version 0.231 no longer exists (it is a local directory on your servers I believe). In my case, it breaks because I use repositoryOverrides which does not include the necessary packages (see load transcript below). If I leave out the repositoryOverrides, the load goes fetching _a lot_ of configurations and packages I never loaded (transitive closure of GsSeaside28, I believe). This is the end of the transcript of a load in my full case. it shows how Metacello starts loading a configuration I am not referencing. --transcript--'Project: Seaside Tests 3.0.10' --transcript--'Fetched -> Seaside-REST-Core-dkh.39 --- http://dev.yesplan.be/gsreplication --- http://dev.yesplan.be/gsreplication' --transcript--'Fetched -> Seaside-GemStone-REST-Core-topa.2 --- http://dev.yesplan.be/gsreplication --- http://dev.yesplan.be/gsreplication' --transcript--'Fetched -> Seaside-Swagger-KrisGybels.35 --- http://dev.yesplan.be/common --- http://dev.yesplan.be/common' --transcript--'Fetched -> CSV-AndyKellens.12 --- http://dev.yesplan.be/gsreplication --- http://dev.yesplan.be/gsreplication' --transcript--'Fetched -> JQWidgetBox-Core-JohanBrichau.4 --- http://dev.yesplan.be/jqwidgetbox --- http://dev.yesplan.be/jqwidgetbox' --transcript--'Fetched -> JQWidgetBox-JEditable-Core-JohanBrichau.4 --- http://dev.yesplan.be/jqwidgetbox --- http://dev.yesplan.be/jqwidgetbox' --transcript--'Fetched -> JQWidgetBox-HoverIntent-Core-JohanBrichau.3 --- http://dev.yesplan.be/jqwidgetbox --- http://dev.yesplan.be/jqwidgetbox' --transcript--'Fetched -> JQWidgetBox-MbMenu-Core-JohanBrichau.21 --- http://dev.yesplan.be/jqwidgetbox --- http://dev.yesplan.be/jqwidgetbox' --transcript--'Fetched -> JQWidgetBox-TableSorter-Core-ThomasCleenewerck.9 --- http://dev.yesplan.be/jqwidgetbox --- http://dev.yesplan.be/jqwidgetbox' --transcript--'Fetched -> SeasideDynamicSVG-Core-JohanBrichau.120 --- http://dev.yesplan.be/SeasideDynamicSVG --- http://dev.yesplan.be/SeasideDynamicSVG' --transcript--'Fetched -> SeasideDynamicSVG-JQuery-JohanBrichau.27 --- http://dev.yesplan.be/SeasideDynamicSVG --- http://dev.yesplan.be/SeasideDynamicSVG' --transcript--'Fetched -> SeasideDynamicSVG-DragDrop-JohanBrichau.15 --- http://dev.yesplan.be/SeasideDynamicSVG --- http://dev.yesplan.be/SeasideDynamicSVG' --transcript--'Fetched -> Seaside-GemStone-ServiceTask-NickAger.20 --- http://dev.yesplan.be/gsreplication --- http://dev.yesplan.be/gsreplication' --transcript--'CONFLICT: a MetacelloAllowConflictingProjectUpgrade occurred (notification 2741) GLASS (0.231)->GLASS (1.0-beta.9)' --transcript--'Project: GLASS 1.0-beta.9' --transcript--'...RETRY->ConfigurationOfGsSeaside28' --transcript--'...RETRY->ConfigurationOfGsSeaside28' --transcript--'...FAILED->ConfigurationOfGsSeaside28' ERROR 2710 , a MetacelloPackageSpecResolutionError occurred (error 2710) (MetacelloPackageSpecResolutionError) Mind that removing/reseting the registry's entry for GLASS fixes this problem immediately. Hope I made some sense... Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Excellent! Thanks for the test case ... I should be able to get to the bottom of this problem now ... I've been battling registry issues (as I've said before) and I avoided image state in the original versions of Metacello to completely avoid these kinds of issues, but calculating the "current version" turns out to be a nearly impossible problem to solve ... Dale On Tue, Jun 24, 2014 at 12:39 PM, Johan Brichau <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |