Nick,
PierModel.gemstone is from an experiment last summer where I was separating code and state, so that one could run Pier without having write permission on the any of the Pier/Magritte/Seaside code ... all class var and class instance var references were mapped to UserGlobals, so for that experiment a branch was useful ... But that package should be ignored. Is it referenced in a configuration somewhere?
The other pier packages with branches do not have significant changes and it should be easy to extract out the platform dependencies with Grease or some other scheme ... Lukas has done a good job of keeping Pier portable ...
These days, I agree that we don't need to keep separate repositories ...
Dale
----- Original Message -----
| From: "Nick Ager" <
[hidden email]>
| To:
[hidden email]
| Sent: Monday, February 20, 2012 5:28:50 AM
| Subject: [GS/SS Beta] Porting Magritte 3 and Pier 3 to Gemstone
|
| Hi,
|
|
| I'd like to be able to use Magritte 3 and Pier 3 on Gemstone. I've
| been examining the Pier 2 port to try to understand how to proceed.
|
|
| Currently there are two repositories
|
|
|
http://seaside.gemstone.com/ss/Magritte2|
http://seaside.gemstone.com/ss/Pier2|
|
| The Magritte port looks quite straightforward as I can reuse most of
| the work in 'Magritte-Gemstone-Model' directly. Also elimination of
| #magritteDynamicObject and caching descriptions should simplify the
| code.
|
|
| However the Pier port looks slightly more involved. Specifically in
|
http://seaside.gemstone.com/ss/Pier2 there are Gemstone branches
| for:
|
|
| Pier-Model.gemstone
| Pier-Setup.gemstone
| Pier-Model.gemstone
| Pier-Setup.gemstone
|
|
| Presumably we should try to avoid creating platform specific branches
| if possible by abstracting the differences? Were the branches
| created for expediency or are there fundamental reasons for the
| branches? Also do you think it makes sense to keep the Gemstone
| specific packages separate from the main Pharo packages?
|
|
| Thanks
|
|
| Nick
|
|
|
|
|
|
Locked
