Loading config maps with circular dependencies

[Bob Nemec]

We're just finishing a port from VW to VAST. VW tolerates circular references in packages, while applications in VAST do not.  My solution was to create a new app with the two circular referenced apps as prereqs, so if A -> and B -> A I added A_B -> A & B.

That process exploded the number of apps from 172 VW packages to 563 VAST apps (with 9632 classes and 54846 methods). We use VAST (and VW before that) to manage GemStone code, using the client Smalltalk dialect for development and testing. Everything runs on GemStone, but we do run a small memory model to work on in VAST / VW.

In order to update GS we build a new client image from the latest published code and push a code update to GS using tools from GemTalk. To build the image we load an 'All' config map that contains all the applications needed. That works fine. However, we'd have five 'squads' which are responsible for a part of the application. To help manage that I've created config maps for each squad, which they will manage. 

The tricky part is how to now load all of their code, given the circular dependencies? I cannot define a clean required map structure, which would be ideal.

What I'm working on instead is to script the updating of the current open 'All' config map with the latest released apps from each squad config map, and load the 'All' config map. But I keep thinking there is a better way, since the dependencies are managed with the 'All' config map is loaded. 

Is there a way to load a set of config maps as if they were one large config map?

Thanks for any recommendations. This has been an interesting and challenging project, but it really feels good to be back in VAST again. 

Bob Nemec

[Louis LaBrunda]

Hi Bob,

I don't know if this will help but I've attached my abt.cnf file.  You can ignore a lot of it.  It works with both Windows and Linux.  It of course runs when VA Smalltalk starts any image.  It knows when it is starting with a clean almost empty/unchanged image (the image from a new release).  You may be interested in the middle section that loads features and then config maps.  I normally load lots of features and the only one config map.  You may want to load many config maps.

I've also attached examples of the files abt.cnf reads.

Lou

[Bob Nemec]

Hey Louis, 

Thanks for the example code. 

We do a similar image build each morning using Jenkins, where we build a base image with the feature we need, and then we use that base image to load our 'all' config map. That works... the challenge is in trying to break up the 'all'  config map that has 566 applications to make is fit the development teams. If it were not for the circular dependencies we just change the 'all' config map to load each squad config map in order. 

[Marcus Wagner]

Hi Bob,

if there is an iron unwritten law: circular dependencies are strictly forbidden.

Zero tolerance. The whole development construct builds upon that.

Solution: you have to break any such dependency - quickly.

Otherwise you cannot load, package or whatsoever.

Its like a broken image.

Sorry.

Kind regards

M

[Davide Grandi]

Hi, just my 2€ cents:

dependencies come from apps, 0classes, inst vars and class pools.

if you have an empty skeleton of these objects, mimicking the full ones, your configuration maps will load without complaints.

You will unload old conf maps, load the skeletons and then load the new conf maps.

You need to adapt these skeletons via scripts, version and release them into the image before loading the conf maps updates.

These scripts will handle the EmShadow* arcana in order to extract class and pool infos and, in the worst case, some methods' source code.

In these days i'm just diving into EmShadow* classes in order to compare and adapt 2 big "source netwoks" of class dependencies: clear to use "since the first sight".

Buona giornata / have a nice day,

    Davide Grandi

(sent from a mobile device: excuse brevity and typos)

--

email: davide...@email.it

linkedin: https://linkedin.com/in/davidegrandi

-------- Messaggio originale --------

Da: Bob Nemec <bne...@gmail.com>

Data: 12/04/26 15:12 (GMT+01:00)

A: VAST Community Forum <va-sma...@googlegroups.com>

Oggetto: Loading config maps with circular dependencies

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/8c9ccd72-724b-4ec8-bd4f-0d9914107103n%40googlegroups.com.

[Marcus Wagner]

I owe an explanation. Without it, my rather rigid posture is easy to be misunderstood.

Of course you can make use of several options to load code into the development image. Feel free.

The point is whether you plan to release your code as a runtime image (without development artefacts, perhaps even headless) or not.

If not, then it we see many other approaches to import something, including such clever skeleton approaches. 

And it is not easy to avoid to smile over such old fashioned rigid constructs and to classify them as arcane.

However if you plan to release a runtime image the whole situation radically changes. Suddenly this process, packaging becomes critical.

At that point my strict attitude begins to pay off.

To give an example: even if you plan to release a simple runtime image without UI (as in a classic traditional command tool or as a service process under Windows) you have to make use of the  XP packager.

Then you depend exactly on its abilities - config maps collecting applications and subapplications with prerequisites and some package rules. No way out.

And my personal experiences told me - if you have to deliver a runtime image (simple or complex, e.g. with overlays, cross platform or not) then being radical always payed off.

Even simple package rules (thought to make this process more comfortable) finally turned out to backfire (such silently has been withdrawn in the meantime, Abt was initially a thankful playgound to make use of such assistance).

And finally, even if your target is not directly packaging, just when offering some support for others (like parts in VA), this strictness becomes a necessity. 

Otherwise everybody making use of such support earns this imported troubles.

This aspect easely is forgotten - in particular as several other development infrastructures are not as strict and offer much more comfort. 

But they are not confronted with the Smalltalk specific packaging problem.

So keep in mind, if your work targets in packaged images, do not provide "modern" delivery concepts without a careful investigation of impacts and risks to packaging.

Kind regards
M

[Bob Nemec]

In our case the code in VAST is only used to update GemStone. Spreading the code into squad responsibility config maps is just to help with code management. My plan was to script the updating of the 'All' config map and load it. Since loading a single config map resolves dependencies in the applications it loads, I figured there would be a way to do the same thing with a set of config maps. Scripting the management of an 'All' config map would work for us, so that's what I'm working on. 

Load the latest apps in config maps A + B + C + D into X and then load X when building the next development image. Developers only have to deal with their own squad's config maps and rest is scripted. 

[Marcus Wagner]

This clarifies and helps me to understand.

First configuration maps (and their variation, feature) are NOT the critical part in supporting you to load s.th. in your image. 

Critical is the load of an application (including its subapplications) and its content, the defined and referenced artefacts (classes, global variables and pools).

An application forms an atomar unit which must have proper prequisites to be successfully loadable. 

Having improper prequisites otherwise will cause the load to fail (leaving artefacts in image to be cleaned up).

It is easy to create an "all" image configuration map -> just add any other application to your config map and collect them using the config map browser, almost only one click. 

But that such an universal map won't help - as loading such a map delegates the load to its apps in a given order, would fail again.

So you will end up at the same.

if the prequisites of an app are not correct, its load will fail or create artefacts (no matter of how you arrange the load in configuration maps, features or other arrangements).

Now to create apps with circular dependencies (as temporary bypass) is a time bomb and will cause unforseeable damage.

You cannot avoid to sit down and solve the simple truth: you cannot load anything before anything else on which it depends. 

Allowing circular prequistes won't change this fact (and as you noted yourself, is escalating the problem, the observed explosion).

As Davide mentiioned here: you need a skeleton first to be able to load its decoration in a second pass. 

And this suggestion is no deviatiion from the principle, it is a confirmation: you cannot load a class in a skeleton without or before its father, so you are already bound to the hierarchical order (parent before children), again. 

Smalltalk is and was strict here (e.g. the major reason of denying multiple inheritance, you remember).

So you have to sit down and determine a strict non circular order of applications. This order determines how and when an application is loaded in your image - not to mention consequences again.

Or you plan to throw the whole code into a single application (perhaps devided by subapplications).

This is a logical consequence of the sequential process of loading.

And besides, if such an order cannot be determined easy, that throws a bad light on the structural architecture of the whole existing material.

It sounds like a natural grown mess.

 

It is the applications structure enforcing such basic architectural principles.  I won't echange that for more comfort.

Kind regards

M

PS: because of the mass of your material it is worth to think about an industrial measure to overcome the current situation and leave that behind.

My idea here is a tool inspecting the given structure, using a topological sort.

It will pinpoint you to all already existing critical hidden circular dependencies, which have to be solved in advance by breaking them.

A universal image wont solve this.

Bob Nemec schrieb am Sonntag, 12. April 2026 um 15:12:02 UTC+2:

[Bob Nemec]

Our app dependencies are clean. As part of my VW Tonel export I mapped circular VW package dependencies to new apps, so that if A & B packages depended on each other I created a new app AB with both A and B a prereqs, where the AB app contained the dependent methods as extensions to classes in both app A and app B. We build a new VAST image each morning with our All config map, loading the 561 apps cleanly. 

All I'm looking to do is to split those 561 apps into separate config maps, one for each team, mostly to make it easier to manage. But splitting the apps into separate config maps introduces circular dependencies between the config maps themselves. My plan is to update the All config map from team config maps, and load the All config for the daily image build. I'm checking if that is a good idea (looking for concerns), or if there is a better way. So far it looks promising. 

Thanks for the detailed responses. 

[Davide Grandi]

Hi to all,

maybe I have to clarify my post.

> And it is not easy to avoid to smile over such old fashioned rigid constructs and to classify them as arcane.

I swear over the Blue Book that my reference to Envy was respectful. In fact a repo architecture standing since ~1994 deserves it.

So I wrote, 2 rows below,

> clear to use "since the first sight"

and I mean "writing the sources of my 4 conf maps, some hundred of applications and a thousand of classes, structured in folders with info text files" was done with a half page st script.

I agree with the rest of the message, with an extra comment about the source migrated between 2 enterprise St: run -> build -> refactor.

(hoping that the source one doesn't move too much, like mine).

Buona giornata / have a nice day,

    Davide Grandi

(sent from a mobile device: excuse brevity and typos)

--

email: davide...@email.it

mobile: +39 339 7468 778

linkedin: https://linkedin.com/in/davidegrandi

-------- Messaggio originale --------

Da: 'Marcus Wagner' via VAST Community Forum <va-sma...@googlegroups.com>

Data: 17/04/26 19:04 (GMT+01:00)

A: VAST Community Forum <va-sma...@googlegroups.com>

Oggetto: Re: Loading config maps with circular dependencies

We're just finishing a port from VW to VAST. VW tolerates circular references in packages, while applications in VAST do not.  My solution was to create a new app with the two circular referenced apps as prereqs, so if A -> and B -> A I added A_B -> A & B.

That process exploded the number of apps from 172 VW packages to 563 VAST apps (with 9632 classes and 54846 methods). We use VAST (and VW before that) to manage GemStone code, using the client Smalltalk dialect for development and testing. Everything runs on GemStone, but we do run a small memory model to work on in VAST / VW.

In order to update GS we build a new client image from the latest published code and push a code update to GS using tools from GemTalk. To build the image we load an 'All' config map that contains all the applications needed. That works fine. However, we'd have five 'squads' which are responsible for a part of the application. To help manage that I've created config maps for each squad, which they will manage. 

The tricky part is how to now load all of their code, given the circular dependencies? I cannot define a clean required map structure, which would be ideal.

What I'm working on instead is to script the updating of the current open 'All' config map with the latest released apps from each squad config map, and load the 'All' config map. But I keep thinking there is a better way, since the dependencies are managed with the 'All' config map is loaded. 

Is there a way to load a set of config maps as if they were one large config map?

Thanks for any recommendations. This has been an interesting and challenging project, but it really feels good to be back in VAST again. 

Bob Nemec

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/8c9ccd72-724b-4ec8-bd4f-0d9914107103n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/d8bc8921-4b21-4472-b08d-2a3cd36a440cn%40googlegroups.com.