Bruno, There was the MockGemstone package that created "compatible" reduced conflict classes (that provide name compatibility but no RC behavior) and other Gemstone globals (such as System) that you can use.
The develop in Pharo deploy in Gemstone is used by a few projects that I'm aware of. As for storing the rules, I rather go with Fuel or GLORP+SQlite. I don't know how complex the object graph can get. But these two options are the most easy to setup, since they have no dependencies and are self contained. Regards, Esteban A. Maringolo On Mon, Sep 30, 2019 at 11:56 AM Smalltalk <smallt...@adinet.com.uy> wrote: > Hi,* > "There was a gemstone workflow engine - it’s not ported, it looked > interesting but used a Windows bpml tool and again wasn’t sure if it wanted > to own the world, and porting it would be more than I wanted to do." > > *I think you are talking about BpmFlow > (https://github.com/brunobuzzi/BpmFlow) if not excuse me :) > > A couple of month ago a created an issue for the port > (https://github.com/brunobuzzi/BpmFlow/issues/843) to annotate all > information related to a possible port. > > The most challenging task is how to persist BpmProcess data within Pharo, use > an ORM (GLORP) or use GemStone ? > This task is the most complex. > > But first there are some minor issue to tackle: > * Replace GS ReduceConflict classes with normal Pharo collections. > * GsQuery > - Replace GsQuery with normal blocks > - (or) Find out if GsQuery was ported (or it could be ported) to Pharo > * Replace GS Selection Block with normal Pharo blocks. {:each | > each.address.state = 'OR'} > > Develop in Pharo and Deploy in GemStone strategy can be a very good source of > information to solve the above issues. > > I use Jade client to directly develop on GemStone/S so a research is needed > on "Develop in Pharo and Deploy in GemStone". > > Modeling tools: > The goal is to be able to import any XPDL file exported by any BPMN tool. > For now we use Bizagi but others tools that export to XPDL standard can be > added. > This will require some effort but is possible (we do an extensive use of > Bizagi extended attributes but if the BPMN tool to be added support some kind > of mechanism to add custom attributes to tasks there will be no problem). > > regards, > bruno > >
