On Fri, Sep 5, 2014 at 6:53 AM, François Stephany <tulipe.mouta...@gmail.com > wrote:
> I have no idea how complicated this can be. I'm a bit reluctant to dive > into this if we are only 2-3 people to use Glorp in Pharo. > > Guillermo, Mariano, what was the process when you imported Glorp in the > first place? How did you keep up with Glorp latest changes (From what I see > in Store, development is not too active)? > > It was a bit complicated. First off, Guille exported all Glorp packages from stone using the "file out" format. These fileout would no import directly into Pharo as I remember, some human or script changes were needed to that these file out could be imported in Pharo. These code was ported under the package Glorp inside our repo. Then the second step was to apply all our changes to Glorp since our changes are not integrated in main stone repostories. These changes are PharoDatabaseAccessor, DatabaseDriver, some changes to Login class and a few other things AFAIK. The third part, was either our special subclass of DatabaseDriver, for either native postgres driver or dbx driver. All that together became GlorpDBX. >From which glorp version we did that port to Pharo, I don't remember and I cannot seem to find it in my old mails. If someone wants to go through these again, then I think you should spend the time so that our changes are integrated in main trunk. Otherwise, future ports will again be a pain. Cheers, > > On Fri, Sep 5, 2014 at 11:30 AM, Stephan Eggermont <step...@stack.nl> > wrote: > >> Sven wrote: >> >Porting something cross platform is a huge amount of work, I think most >> of it was basically done by hand. >> >This creates a huge maintenance problem of course. The same is true for >> Xtreams. >> >Seaside seems to be able to manage this problem by being extremely >> careful. >> >> We now have the infrastructure in place (CI) that supports a much better >> approach. >> We could use a vw image to download the current version from the public >> store >> and generate the platform-independent mczs from there. That of course >> requires >> changes to the VW code base to create and use platform classes. That is >> similar to >> what we did in the other direction with Parasol, what Roassal does and >> Seaside. >> If we make the (namespace) transformations explicit, we should be able to >> sync >> in two directions. >> >> Stephan >> >> >> >> > -- Mariano http://marianopeck.wordpress.com
