You are currently browsing the monthly archive for June 2010.
As most of you are probably aware, the SqueakSource server has been a little unstable over the last few weeks. To add insult to injury, the GemStone data center went down for several hours last week, as well. With GemSource offline, it isn’t possible to bootstrap Metacello. During the email exchange on the Pharo mailing list, it came up that as of Metacello 1.0-beta.25, I had started maintaining an alternate repository that could be used if GemSource was unavailable (some manual assembly required).
With the 1.0-beta.27 release, the Metacello bootstrap process automagically uses the secondary repository (http://www.squeaksource.com/metacello) if the primary repository (http://seaside.gemstone.com/ss/metacello) is not available. That means that as long as either SqueakSource or GemSource is online, you will be able to bootstrap Metacello.
The 1.0-beta.27 release goes beyond bootstrapping Metacello. A couple features were added (or bugs fixed if you are so inclined) that make it possible for you to leverage redundant repositories in your own Metacello project.
- Secondary repository.
- Copy mcz files to secondary repository.
- Add secondary repository to baseline spec.
- Project reference with secondary repository.
First you need to create Monticello projects on a second server. This is probably the toughest problem since there aren’t that many public SqueakSource repositories out there. Within GemStone we have plans to create an additional, public GemSource repository, but those plans haven’t materialized yet. Perhaps the instability of the SqueakSource server may spur the creation of additional public repositories.
Second, you need to arrange to copy your mcz files to the secondary repository whenever you release a new version of your configuration. I’ve published the script that I use for copying Metacello mcz files to http://www.squeaksource.com/metacello. The script can be modified for use in your own project.
Third, you need to create a baseline version that references the secondary repository. As an example, I’m adding a secondary repository to the configuration of Gofer by copying the spec for 1.0-baseline which looks like the following:
baseline100: spec <version: '1.0-baseline'> spec for: #common do: [ spec blessing: #baseline. spec repository: 'http://seaside.gemstone.com/ss/metacello'. spec package: 'Gofer-Core'; package: 'Gofer-Tests' with: [ spec requires: 'Gofer-Core' ]. spec group: 'default' with: #('Core'); group: 'Core' with: #('Gofer-Core'); group: 'Tests' with: #('Gofer-Tests'). ].
baseline1021: spec <version: '126.96.36.199-baseline'> spec for: #common do: [ spec blessing: #baseline. spec repository: 'http://seaside.gemstone.com/ss/metacello'; repository: 'http://www.squeaksource.com/metacello'. spec package: 'Gofer-Core'; package: 'Gofer-Tests' with: [ spec requires: 'Gofer-Core' ]. spec group: 'default' with: #('Core'); group: 'Core' with: #('Gofer-Core'); group: 'Tests' with: #('Gofer-Tests'). ].
Yep, that’s all it takes …
Finally, if you want to reference a project where the configuration is saved in a primary and secondary repository (in this case, http://www.squeaksource.com/MetacelloRepository and http://seaside.gemstone.com/ss/metacello) then you can do something like the following:
spec project: 'Gofer Core' with: [ spec className: 'ConfigurationOfGofer'; repository: 'http://www.squeaksource.com/MetacelloRepository'; repository: 'http://seaside.gemstone.com/ss/metacello'. ].