GemStone code management techniques

Hi,

 

We're interested to know what techniques other GemStone users are using for their GS Smalltalk code management and deployment processes, hence a few very general questions to anybody inclined to answer:

 

1)      What tools/editors do you use for writing GS Smalltalk code?

2)      What packaging system do you use for organising your code and separating out your extensions to core classes from GemTalk Systems' own code?

3)      Which version control system do you use, and in what kind of structure do you store your code (what does one file in your source code repository represent, if file-based)?  How do you extract a deployable set of changes from your version control system?

4)      What mechanism do you use for uploading code to your production GemStone DB?

 

Any feedback much appreciated!

 

Thanks and regards,

Martin

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

Libre de virus. www.avast.com

Hi Martin,

One solution with a long history is called GemKit. GemKit allows GS/S code to be maintained using the same code repository and development tools as a client dialect of Smalltalk (VisualAge or VisualWorks). GemKit is designed to work in conjunction with GemBuilder for Smalltalk (GBS).

GemKit started as a framework developed by GemStone Consulting at customer sites with updates shared between customers. It was sold as a product for several years and then had several years of abandon. While employed with GemStone/GemTalk I refined it into a product that was released under an open source license for anyone to use. It was originally ENVY/Developer based, so it worked with VisualSmalltalk, VisualWorks, and VisualAge. At that time I had refined it to have a common code base for all three ENVY supported dialects. I ported it to VW Store (with assistance from Joseph Bacanskas) at a Camp Smalltalk event in Colorado. I significantly refined GemKit after my time with GemStone as new employers needed it. Currently there is a GemKit for VisualAge (that I developed at WAMU) and a GemKit for VisualWorks (that I developed at ICE). For both variants I had separately refactored about 90% of the code. There are now easier maintained object models in both, but the models were created at different times and are not the same between VA and VW. GemKit was open source and had also evolved from the original consulting code. There are likely several variants all called "GemKit". David Buck had ported GemKit for VW to a newer version of VW for one of his clients, ICE also uses GemKit for the latest VW but by different effort. I no longer maintain this code and have no idea whether David or ICE would be the best source for updates to that code. Sharing of changes is expected by the open source license, but there is no incentive system to do this and so code just disappears as companies do. Older versions may exist on SourceForge.

Answers to your specific questions:

1) GemKit uses the native code management tools of VA (ENVY) or VW (Store). GS code is maintained through a client image that immediately updates GS if there is an active session. It is possible to manage GS code without a GS session and update GS later either by code comparison tools or by change scripts. All special tools (like code refactoring) are available to GS code through GemKit.

2) GS code is traditionally stored in separate "GS_" prefixed applications/packages. Newer versions of GemKit allowed a package to contain a mix of client and GS code (distinction was at the class level rather than by package). Class extensions are fully supported just as you would expect it to work for client code.

3) I also created version control systems for both WAMU and ICE. That was never part of the original GemKit. The version control system is effectively part of GemKit now. The original GemKit produced GS fileouts. The newer GemKit can also produce fileouts as change sets and that have better support for GS class extension permissions. The release tools were designed to incentivize developers to quickly integrate their working changes to reduce code merge effort and generally reduce bugs from delayed integrations. It was compliant with all the buzzwords expected now, before the buzzwords were thought of. The release tools proved extremely important for team productivity and build quality.

4) Interactive updates can be made by logging into GS and comparing a loaded or specific version of code with what exists in GS. Releases are typically deployed with GS patch files (.gs fileout). A fileout can be produced for all the code of a release or to bring code from any specific version up to a targeted version. GS class extension code (that requires SystemUser or DataCurator login) is in a separate but similarly named "_extensions.gs" patch file. When a class schema is changed then a patch will include all the code of all subclasses too. Class migrations and version-specific update code is traditionally part of the .gs update script. If you create a patch to go from version 1 to 10 and there are several version and that have pre and post migration code then that pre and post code is automatically combined to work as you would hope. At ICE they wanted to separate and customize this code for each upgrade, and so that is possible too.

I have the impression that GemTalk is finding reduced customer demand for GBS. That means that GemKit is less used too. GemTalk now has more emphasis on web clients and code management through Monticello and git. GemKit is an established way of GS code management that is again falling to neglect. GemKit might possibly be the best solution out there but there isn't much of a market to share a specialized tool like this. GemKit became significantly refined over the years but you'll still find some messy code in there. It works well though and has had years of mission-critical utility. In a very real sense, GemKit for VW has such utility that it alone can be a reason to buy licenses for VW and GBS. GemTalk stands behind Monticello, so you might try that solution first to see if it meets your needs.

Paul Baumann

Retired from Software Development

Hi,

 

We're interested to know what techniques other GemStone users are using for their GS Smalltalk code management and deployment processes, hence a few very general questions to anybody inclined to answer:

 

1)      What tools/editors do you use for writing GS Smalltalk code?

2)      What packaging system do you use for organising your code and separating out your extensions to core classes from GemTalk Systems' own code?

3)      Which version control system do you use, and in what kind of structure do you store your code (what does one file in your source code repository represent, if file-based)?  How do you extract a deployable set of changes from your version control system?

4)      What mechanism do you use for uploading code to your production GemStone DB?

 

Any feedback much appreciated!

 

Thanks and regards,

Martin

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk