Creating a "pristine" image config map

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Creating a "pristine" image config map

vinref
Hi

I am attempting to create a config map for a "pristine" development image. Past practice was to pass an image around from developer to developer, but I have discovered that some images in the wild have different loaded versions of the core applications, and some have new editions. Debugging can be extremely laborious.

A naive first approach is to add all core application config maps as required maps, but there are quite a lot. Is there a cleaner way to do this?

Vince

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Creating a "pristine" image config map

SebastianHC
Hi Vince,

your "naive" approach is definitely the best approach to deal with the requirements within your application.
I usually define several configurationmaps for my projects. This results in a tree of configmaps that require other configmaps of your own,... Those configmaps are either related to particular parts of the application (core, webservices, testing-tools, DB-Access,...), for different stages of the release (release X.Y, bug-fixing X.Y ) or different types of development (prototyping, development, testing, production,...)

However, at first, you might want to focus on loading full packages that support particular technologies into the image. Things like ServerSmalltalk, Seaside, XML support, ... the applications with these parts are already defined as configuration maps and you are well advised to use them because it makes updating from one VASmalltalk version to another much easier.
Have a look at the Transcript window. There is an entry that says: "load and unload features". Here you can see all the pre-fabricated "packages" that VASmalltalk provides.
- Write down the names of those that you need in your application.
- Then open the ConfigurationMaps browser and scroll down to the bottom.
- There are similarly named configuration maps with different prefixes (sorry, I can't look those up from here right now. it is something like abx., or sst.,...) Those are the configurationmaps that relate to the packages in the "load unload features" tool.  Use those as a requiredmap in your own configurationmap to load most of the code needed by your developers.

Once you have defined your own configurationmap(s) you can define a new configurationmap with such prefix, having your configurationmap as a prerequisite, to make it show up in the "load and unload feature" tool, too. The "load and unload feature" tool scans the list of configurationmaps for these prefixes to pick "features" for selection. This would allow your developers to load all needed code into a "pristine" image without even opening the configurationmap browser at all... well, if done properly...

There should be information on the help website of Instantiations on that, too.

I hope that is not more confusing,... but try to take what is already there.

Sebastian


On 2017-12-26 09:02 PM, Vince Refiti wrote:
Hi

I am attempting to create a config map for a "pristine" development image. Past practice was to pass an image around from developer to developer, but I have discovered that some images in the wild have different loaded versions of the core applications, and some have new editions. Debugging can be extremely laborious.

A naive first approach is to add all core application config maps as required maps, but there are quite a lot. Is there a cleaner way to do this?

Vince
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.




On 2017-12-26 09:02 PM, Vince Refiti wrote:
Hi

I am attempting to create a config map for a "pristine" development image. Past practice was to pass an image around from developer to developer, but I have discovered that some images in the wild have different loaded versions of the core applications, and some have new editions. Debugging can be extremely laborious.

A naive first approach is to add all core application config maps as required maps, but there are quite a lot. Is there a cleaner way to do this?

Vince
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Creating a "pristine" image config map

vinref
Hi Sebastian

Thank you! I have learned something new today - the listings at the bottom of the config map browser are "meta" config maps: the ones prepended by "z" are collections of config maps into functional packages, and the ones prepended with "zz" are collections of those.

This will make things a lot easier to manage.

Vince

On Thursday, 28 December 2017 04:04:06 UTC+10, Sebastian Heidbrink wrote:
Hi Vince,

your "naive" approach is definitely the best approach to deal with the requirements within your application....

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Creating a "pristine" image config map

SebastianHC
You are very wekcome!

Glad that it was helpful to you.

Happy new organized year!
Sebastian


On 2017-12-27 05:04 PM, Vince Refiti wrote:
Hi Sebastian

Thank you! I have learned something new today - the listings at the bottom of the config map browser are "meta" config maps: the ones prepended by "z" are collections of config maps into functional packages, and the ones prepended with "zz" are collections of those.

This will make things a lot easier to manage.

Vince

On Thursday, 28 December 2017 04:04:06 UTC+10, Sebastian Heidbrink wrote:
Hi Vince,

your "naive" approach is definitely the best approach to deal with the requirements within your application....

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Creating a "pristine" image config map

jtuchel
In reply to this post by SebastianHC
Seabastian, Vince,


the approach you mention is the "correct" one and we have been using it for years.

There are some shortcomings, however:

  • The req maps concept does not provide something like "load the current official version of Server Smalltalk/Seaside/Whatever as shipped with the current VA ST release". You always reference an exact version. Not sure, but I think some kind of conditional version reference or blessing level could help a lot here
  • When cross-packaging (e.g. for a headless image) some of the provided maps are not suited for loading into the passive image as they contain applications that cannot be packaged headlessly. So there is some work to do on your own to dig into the maps and select the ones to really load into an XD image. Unfortunately, I don't have any concrete examples at hand. I just remember it was a long process of trial and error after each Version Change. I hear that things have improved steadily from 8.0 to 8.6, we just kept our maps and load the newer versions.. (I think Marten has provided a lot of feedback to Instantiations for this topic)

Just a few thoughts

Joachim



Am Mittwoch, 27. Dezember 2017 19:04:06 UTC+1 schrieb Sebastian Heidbrink:
Hi Vince,

your "naive" approach is definitely the best approach to deal with the requirements within your application.
I usually define several configurationmaps for my projects. This results in a tree of configmaps that require other configmaps of your own,... Those configmaps are either related to particular parts of the application (core, webservices, testing-tools, DB-Access,...), for different stages of the release (release X.Y, bug-fixing X.Y ) or different types of development (prototyping, development, testing, production,...)

However, at first, you might want to focus on loading full packages that support particular technologies into the image. Things like ServerSmalltalk, Seaside, XML support, ... the applications with these parts are already defined as configuration maps and you are well advised to use them because it makes updating from one VASmalltalk version to another much easier.
Have a look at the Transcript window. There is an entry that says: "load and unload features". Here you can see all the pre-fabricated "packages" that VASmalltalk provides.
- Write down the names of those that you need in your application.
- Then open the ConfigurationMaps browser and scroll down to the bottom.
- There are similarly named configuration maps with different prefixes (sorry, I can't look those up from here right now. it is something like abx., or sst.,...) Those are the configurationmaps that relate to the packages in the "load unload features" tool.  Use those as a requiredmap in your own configurationmap to load most of the code needed by your developers.

Once you have defined your own configurationmap(s) you can define a new configurationmap with such prefix, having your configurationmap as a prerequisite, to make it show up in the "load and unload feature" tool, too. The "load and unload feature" tool scans the list of configurationmaps for these prefixes to pick "features" for selection. This would allow your developers to load all needed code into a "pristine" image without even opening the configurationmap browser at all... well, if done properly...

There should be information on the help website of Instantiations on that, too.

I hope that is not more confusing,... but try to take what is already there.

Sebastian


On 2017-12-26 09:02 PM, Vince Refiti wrote:
Hi

I am attempting to create a config map for a "pristine" development image. Past practice was to pass an image around from developer to developer, but I have discovered that some images in the wild have different loaded versions of the core applications, and some have new editions. Debugging can be extremely laborious.

A naive first approach is to add all core application config maps as required maps, but there are quite a lot. Is there a cleaner way to do this?

Vince
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="6HZahP5RAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="6HZahP5RAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.




On 2017-12-26 09:02 PM, Vince Refiti wrote:
Hi

I am attempting to create a config map for a "pristine" development image. Past practice was to pass an image around from developer to developer, but I have discovered that some images in the wild have different loaded versions of the core applications, and some have new editions. Debugging can be extremely laborious.

A naive first approach is to add all core application config maps as required maps, but there are quite a lot. Is there a cleaner way to do this?

Vince
--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="6HZahP5RAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="6HZahP5RAwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.