[GemStone-Smalltalk] GemStone code management techniques

Mon Dec 4 13:43:11 PST 2017

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

On 12/04/2017 09:47 AM, via GemStone-Smalltalk wrote:
>
> 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
> GemStone-Smalltalk at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20171204/4f92a844/attachment.html>