Hi Dale,
Every in a while (i cannot yet understand exactly when), I try to update the code of my app via the webinterface (we have a button for that) and I get an exception saying: " Warning: You are about to load new versions of the following packages that have unsaved changes in the image. If you continue, you will lose these changes. Bootstrap" The code I use to update my app is: [ [ [ Metacello image configuration: 'IAM'; version: '1.5'; onLock: [:ex | ex honor]; load: #('Core' 'DPOFX'). ] on: MetacelloAllowConflictingProjectUpgrade do: [ :ex | ex defaultAction ] ] on: MetacelloAllowLockedProjectChange do: [ :ex | ex disallow ] ] on: MetacelloNameNotDefinedError do: [ :ex | ex resume ]. As far as I know, I have already migrated to latest GLASS, Seaside, Metacello and Magritte some months ago. Any idea what could be going on? I also attach the full stack in case this helps. In addition, let me tell you something even stranger. My app (ConfigurationOfIAM) loads a package called Bootstrap-Core (which is Twitter Framework) this way: spec package: 'Bootstrap-Core' with: [ spec requires: #('Seaside'); repository: 'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main/' ]. (note I am referencing directly the package rather than a project ref..but that's another discussion). I have also noted that sometimes, if I click proceed in the above warning, the twitter bootstrap package (Bootstrap-Core) is a bit corrupted...classes no longer exists and the extension methods (over WAHtmlCanvas etc...) disappear as well... Considering all the Monticello thingies of packages and subpackages and the fact that Bootrstrap-Core is a substring of Bootstrap, that make me doubt. Any thoughts? Thanks in advance, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass bootstrapUpdateProblem.html (229K) Download Attachment |
Hi Dale, Of course, it was BaselineOfGLASS1, not ConfigurationOfGLASS1. Anyway, I continue investigating this problem. It might be related to #reprimeRegistryIssue197 Besides the stack track I attached previously, here I attach the transcript of the load. These are the last lines: Project: XMLSupport 1.2.2 Project: SIXX baseline Project: XMLSupport stable [1.2.2] Project: XML-Writer 1.0.5 Project: Grease Core 1.0.3 Evaluated -> 1.0-alpha2.2 [ConfigurationOfGoferProjectLoader] >> postLoadLoader Evaluated -> baseline [BaselineOfMetacello] >> reprimeRegistryIssue197 And that's when the popup halts warning about loading Bootstrap again. In addition, I made sure to run GsUpgrader upgradeGrease just in case, and this was the output: ====================== =====Metacello Preview already loaded ====================== =====Upgrading Metacello Fetched -> BaselineOfMetacello-dkh.85 --- github://dalehenrich/metacello-work:master/repository [972b098:master] --- github://dalehenrich/metacello-work:master/repository Loaded -> BaselineOfMetacello-dkh.85 --- github://dalehenrich/metacello-work:master/repository [972b098:master] --- github://dalehenrich/metacello-work:master/repository Loading baseline of BaselineOfMetacello... Project: FileTree baseline Project: Gofer stable [1.0.5.1] Evaluated -> baseline [BaselineOfMetacello] >> reprimeRegistryIssue197 ...finished baseline Migrated 0 instances for 2 classes. ====================== =====Upgrading Grease Fetched -> BaselineOfGrease-JohanBrichau.7 --- github://GsDevKit/Grease:master/repository [00a7df6:master] --- github://GsDevKit/Grease:master/repository Loaded -> BaselineOfGrease-JohanBrichau.7 --- github://GsDevKit/Grease:master/repository [00a7df6:master] --- github://GsDevKit/Grease:master/repository Loading baseline of BaselineOfGrease... Project: UTF8 stable Project: Core 0.247 Project: XML Parser 1.0.5 Warning: LOCK ENFORCED: Attempt to 'load with conflicts' new project: 'ConfigurationOfGrease 1.0.3 from http://www.squeaksource.com/MetacelloRepository' when existing project: 'BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository' is locked. New project not loaded. Use #onLock: to intercept. Project: XML-Writer 1.0.5 Warning: LOCK ENFORCED: Attempt to 'load with conflicts' new project: 'ConfigurationOfGrease 1.0.3 from http://www.squeaksource.com/MetacelloRepository' when existing project: 'BaselineOfGrease [baseline] from github://GsDevKit/Grease:master/repository' is locked. New project not loaded. Use #onLock: to intercept. Project: Grease Core 1.0.3 Project: UTF8 stable Project: System-Digital-Signatures stable Project: SMTPMail stable Project: System-Digital-Signatures stable Project: SMTPMail stable ...finished baseline No instance migrations performed. So.... Grease seems indeed locked. So I don't understand why the above lines "Project: Grease Core 1.0.3" try to load Magritte if I said " onLock: [:ex | ex honor]; " of my load and also surrounded via a " on: MetacelloAllowLockedProjectChange do: [ :ex | ex disallow ] ]" What is funny is that reprimeRegistryIssue197 seem to have been executed in both places (when I tried to load my code and with #updateGrease). With my app, I got the warning trying to update Bootstrap. With #upgradeMagritte it said nothing. I also attach the project and package report from GsUpgrader. Any idea what could be going on? I may know how to workaround it, but I wanted to share this in case it's a Metacello bug or something. Thanks in advance, On Wed, Feb 11, 2015 at 3:21 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass loadOrder.txt (5K) Download Attachment packageReport.txt (9K) Download Attachment projectsReport.txt (1K) Download Attachment |
In reply to this post by GLASS mailing list
Mariano,
This email went into the google spam folder, so I didn't know it had been sent until you replied ... sorry about that... You mention that there are two separate packages named "Bootstrap" and that is definitely the source of the Warning and could cause additional problems if not taken care of. The way the Monticello works is that there are going to be two separate packages defined: - Bootstrap - Bootstrap-Core If you happen load a new version of the Bootstrap package, then more than likely the entire contents of the Bootstrap-Core package will be removed from the system ... You didn't mentioned this particular issue yet (the last update to the Bootstrap package was in Jaunuary 16, 2015), but in the future if a new version is created, you can expect this to happen. When you load a new version of Bootstrap-Core nothing in Bootstrap should be removed from the system, but the system will think that all of the Bootstrap-Core code "belongs" to the Boostrap package. I can easily imagine that at a minimum the Bootstrap package could get marked as dirty when the Bootstrap-Core is loaded ... immediately after a load, the package is marked clean because it is marked as durty during the load and the Bootstrap package would not be cleaned up in this way. I don't have the bandwidth right now to go fiddling around with GLASS1 package names, so for the near term I would suggest that 1. you ask Torsten to rename his packages ... 2. copy the Bootstrap-Core package to your IAM repository and then rename the package yourself. Unfortunately I think it is cleaner to rename a Monticello package by creating a new package and then "moving" the definitions into that new package and then saving it ... You lose all of the history this way, but when you save a package by just renaming it in the save prompt, you are not changing the underlying package name, and you will have even nastier problems ... I think ... If you want to be able to merge upstream changes, you can try doing an `adopt` on the old package and that might work, but I've never tried it ... If you are using a git repository for your IAM project, then things aren't nearly as bad. Git doesn't need the monticello history to manage the rename and the process you'd use is: 1. create a branch for the rename work 2. copy the Bootstrap-Core package into the git repo. 3. commit 4. do the package rename as mentioned above (i.e., create a new package and "move" definitions) 5. save the new package to your repo 6. `git rm -rf` the old package directory 7. commit 8. merge this branch into you master branch At this point git will have recognized that you've done a rename of all of the definitions in the package. To merge in a new version of the origin Bootstrap-Core package: 1. checkout a new branch branch at the commit from step 3, above 2. copy the new version of Bootstrap-Core into the repository 3. commit 4. checkout your master branch 5. merge the new branch into the master (git merge --no-ff --no-commit) At this point you should have all of the changes in your master branch and unless you've made changes to the contents of Bootstrap-Core three should be no conflicts, either. Make sure that you've installed GitFileTree-MergeDriver[1] before doing the merge ... everyone using git and monticello should use this project ... it automatically merges the monticello meta data (version file, and methodProperties files) for you ... Also, be aware of the fact that on a merge into a renamed package that class categories and method protocol names need to be manually edited. The latest version of FileTree has a consistency check for this[2]. So that's pretty much "my thoughts" on this:) Dale [1] https://github.com/ThierryGoubier/GitFileTree-MergeDriver [2] https://github.com/dalehenrich/filetree/issues/136 On 02/11/2015 10:21 AM, Mariano
Martinez Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Mariano,
Just a note about your load expression. I can imagine that depending upon which version of Metacello you are using, one or more of the handlers that you are using would have been necessary, but if you can depend upon using the latest version of Metacello, then you can streamline things a bit:): [ [ [ Metacello image configuration: 'IAM'; version: '1.5'; onLock: [ :ex | ex honor ]; load: #('Core' 'DPOFX') ] on: MetacelloAllowConflictingProjectUpgrade do: [ :ex | ex defaultAction ] ] on: MetacelloAllowLockedProjectChange do: [ :ex | ex disallow ] ] on: MetacelloNameNotDefinedError do: [ :ex | ex resume ] The onLock: block is already handling the MetacelloAllowLockedProjectChange exception. You can use an onConflict: method in the load expression to handle the MetacelloAllowConflictingProjectUpgrade exception, but in your case since you explicitly invoking the defaultAction, you probably don't need one. In fact, you probably no longer the need the onLock, because the default behavior is to honor locks. There also an onWarning: or onWarningLog method that you can use ... Dale On 02/11/2015 10:21 AM, Mariano
Martinez Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |