Products and Modules
Smallworld Magik-Sources and Resources are organised within modules, defined by a module.def file in their root directory, which defines amongst other things the name and version of the modules and the names (and versions) of other modules, which are required to be loaded before the code of the defined module. The source code files for the module are defined by load_list.txt files in the module's root directory and recursively in child directories, as long as they are listed in their parent directory's load_list.txt file.
Several Modules may be organised within layered products, defined by a product.def file in their root directory. Layered product may also be located below another layered product. The call smallworld_product.add_product(<path-to-a-product's-root-directory>) makes the product and all its modules (including the layered products in subdirectories and its modules) known to the current session.
Then a module is known to the session, its code can be loaded by sw_module_manager.load_module(<name-of-the-module>). If some of the required modules are not yet loaded, their code is loaded before.
There are some techniques how code loading is accelerated:
up to SW 4.3
When loading a module the code is loaded from compiled magik files (*.magikc) if they are available and newer than the corresponding *.magik file. If not, the code is loaded from a *magik file, if available, and by default a *magikc file is generated for accelerating the next load of the module.
Compiled magik files are no longer supported. Instead the compiled code of a module may be saved to single *jar file in a libs directory of the top most layered product, in which the module resides. The jar file's name includes its layered product's and module's name separated by a dot.
Furthermore the initialising of a product may be accelerated by genearting a *ser file of the product's structure. If such a file is present, the smallworld_product.add_product() command reads all informations on modules etc. from this file without parsing the directory tree.
Dependencies on the loading order of modules
In an ideal world all modules depend only on their required modules and besides that they are completely independent. If each module defines only methods on classes defined within that module, and each class is defined within one modules only, we should be quite sure to have such an ideal constellation. In fact there are many possibilities to produce depencencies which cause the result of loading some modules depends on the order in which these modules are loaded. And probably for each possibility you'll find at least one example in a module GE or a partner sells to customers.
Unfold the following points to see details:
A remark on *jar file generating with SW 5.0
When using the <a-product>.compile_all_modules() in most of the a.m. examples the result doesn't depend at all on the question, whether the *jar file(s) are already generated. An important exception is the auto declaration of globals in different packages as described above.