Well, now you can do just that! I’m offering MPS Office Hours, a regular group call where you can demonstrate your problem and get hints from myself or other present experts.

And if you don’t have a problem yet but just want to watch and learn from others, you can, too!

Best of all, it’s free!

I wasn’t expecting to participate in the Office Hours today. My plan was to just watch and learn. I’m used to the try-it-and-see and RTFM before asking for help. Still, I’m glad that I did participate, got good feedback and pointers. It’s a valuable resource for the community.

– Nuba Princigalli

Interested?

Here are the important details:

• The call takes place every Monday and Thursday from 14:30 until 15:00 CE(S)T (GMT+1 or +2, dependent on daylight savings).
• We meet on Google Meet. To avoid zoombombing, the link is not shared publicly but will be posted to the #office-hours channel in the offical MPS Slack.
• Discussion related to MPS Office Hours also takes place in the #office-hours channel.
• The office hours are not recorded currently but this may change in the future.
• Attendance is free and the meeting is public. If you want a private consultation, contact me.

To help reduce the risk of your team getting stuck on a difficult issue, I offer MPS Advisory Service where I answer your technical questions related to MPS with a response time of one business day.

Examples of topics that are covered

• How to implement a particular editing feature
• Understanding an error message and suggestions on how to best fix the underlying cause
• How to automate the build process
• How to best integrate MPS with a particular system or environment

What is not covered

• Developing production code – but I might create a small example to illustrate a point or a technique, if necessary.
• Maintaining or debugging existing code – but I could give you tips to help you do it.

How it works

The service is offered to you as a single person (a team lead, an architect, a CTO). You ask questions by email, I reply to my best ability within one business day, but usually faster. If necessary and convenient, we may jump on a videocall to understand the problem better, but the service is mostly asynchronous.

Terms

• The service costs 3 000 EUR/month (30 days), paid in full in advance.
• In case of vacations/holidays the duration of the service is extended.
• To ensure a high quality of service I only take 2 clients in a given month.

Interested? Contact me at sergej@specificlanguages.com.

MPS

The list below only mentions user-visible changes and does not include refactorings such as dead-code removal or moving functionality around.

BaseLanguage

• 🆕 IForEachLoop interface to capture commonalities between various foreach loops.
• ↗️ Intention ‘Add Field For Unused Param’ got a slightly nicer name
• ↗️ BaseLanguage no longer depends on the behavior language
• ↗️ Resolution of unknown elements during Java parsing will not add a used language when it already comes from a used devkit.
• 🐞 Fixed a few NPEs when accessing scope or class hierarchy for a detached node

Behavior language

• ↗️ Generated code changes to improve diagnostics: parameter names are now tracked, no code is generated for empty constructors, and invoking some internal implementation methods directly to shorten stack traces.
• ↗️ Removed the dependency of the behavior language on the kernel subsystem.

Core

• ↗️ Diagnostics improvements (better printout from ClassLoaderManager, extra trace from EDTExecutor).
• ↗️ Continued internal refactoring towards per-project repositories.

Editor

• ↗️ The : cell was made non-selectable in Boolean style items.
• ↗️ Avoid auto-fixing references in nodes that are no longer open in the editor.

Find Usages

• ↗️ A nicer tab name for module dependency usages.

Make

• ↗️ The RCP build script wizard was updated to reflect the fact that the MPS Make plugin now depends on the Java plugin.

Migrations

• ↗️ Minor improvements in the migration notification (“Some languages in the project are not deployed…”)

MPS-extensions

• 🆕 blutil language was extended with several additional operations, such as ’elvis’ operator ?:, integer ranges ([2..5]), select with index, and more. For more details, see the changelog.

• 🆕 EditorTestLifecycleMethods attribute and related intentions were added to the nl.f1re.testing language. With these intentions you can add before/after tests methods to editor tests.

• 🐞 de.itemis.mps.linenumbers Improve line numbers position in diff editors where the line numbers appear to the right of the editor.

• 🐞 de.itemis.mps.linenumbers Fix a NullPointerException that would occur after application shutdown and would be logged e.g. by command line tools. The NPE was caused by failing to properly dispose a Swing timer.

• 🐞 de.itemis.mps.editor.celllayout.runtime Grid layout was broken after previous performance optimization

mbeddr platform

Bugfixes to several languages:

• 🐞 com.mbeddr.mpsutil.filepicker: Solution-relative pickers now work correctly during generation.
• 🐞 com.mbeddr.mpsutil.hyperlink: random exceptions should no longer occur after module reload.
• 🐞 com.mbeddr.mpsutil.interpreter: Throw a more detailed exception when TypedChildConstraint cannot determine the type of a node.
• 🐞 com.mbeddr.mpsutil.interpreter: Generated node URLs now correctly point to the input model instead of the transient model.

KernelF

• no changes in March

mbeddr/mps-gradle-plugin

• 🐞 A minor fix to the MpsMigrate: pass an additional --add-open argument to MPS so that versions 2025.1 and above do not complain at run time.

mps-build-backends

• 🐞 A few fixes to get fewer stack traces logged during backend execution.
• 🆕 The execute backend can now exit with a custom error code: if the executed method returns an integer value, this value is used as the backend exit code.

Other projects

• Eugen Schindler from DSLFoundry wrote in to mention that he recently migrated two DSLFoundry projects to MPS 2025.1: mps-UMLRT and mps-metabnf.

• MetaBNF seems to be a catchy name because this is also the name of a new project open-sourced by Porsche. Both projects appear to be focused on generating MPS DSLs from a Backus-Naur Form (BNF) description.

MPS

The main areas of work in February were:

• closer integration with the IDEA platform and being a good citizen of it,
• refactorings and improvements towards replacing the global repository with per-project repositories (a long-term effort),
• deadlock hunting,
• removal of deprecated code,
• various minor bug fixes in areas such as base language data flow with commented out nodes, proper cleanup in editor tests in case of failure, and handling of Java source stubs (MPS models created based on Java sources, as opposed to compiled class files).

MPS-extensions

Optimizing performance of editors showing many similar kinds of images (e.g. checkboxes) and editors using the celllayout language which installs a layout interceptor to modify how MPS lays out its editors.

Line numbers now properly appear when a new editor is opened.

mbeddr

A new language to visualize generator plans, com.mbeddr.mpsutil.genplandiagram.

IETS3 Opensource

• Variability-related improvements

mps-build-backends

In the execute backend (which is a replacement/improvement over the run mps code MPS functionality and the corresponding runMPS Ant task) if the executed method returns an integer value, it will be used as the exit code of the backend. This allows the caller to distinguish between several error conditions.

Additionally, project-loader got some workarounds so that a few scary-looking but harmless stack traces that appeared during MPS startup and shutdown will no longer be logged.

mbeddr/mps-gradle-plugin

The plugin had a minor update to upgrade the dependencies it uses. It will now work with the current MPS prerelease.

MPS

There have been quite a lot of changes in January, so I am splitting them by subsystem.

AI

• Include the mcp-server plugin from IDEA in MPS.

Base Language

• Refactoring: moving code around to reduce the number of cyclic dependencies in the subsystem.
• Classifier.isDescendant() optimized to avoid loading stubs unnecessarily and walk the class hierarchy more efficiently.

Editor

• Cleanup: a deprecated 2-argument cell factory method in the editor language generator was removed, only the no-argument version remains. This affects authors of custom editor cells.

Migrations

• Cleanup: removed unused code, old project migrations (2020 and earlier).
• Refactoring of internals to improve the internal API and reduce the need for model read lock.
• Changes around how language versions and module dependencies are computed - less guessing, version -1 will be used if not stored.

Model Persistence

• New version of binary model persistence (.mpb files). The format now stores versions of languages used by the model. This is related to the changes in the migration subsystem.

Project

• Continued preparations for closer integration with the IDEA platform (workspace model)

Structure

• Cleanup: EnumDataTypeDeclaration_Old and related concepts deprecated several years ago were removed.
• Internal: show ‘concept scope’ in developer mode (concept scope is an experimental, internal feature to designate some concepts as non-referenceable or only referenceable from within the same root node).

Testing

• Cleanup: drop previously deprecated concepts for node tests (NodeTypeSystemWarningCheckOperation and CheckNodeForErrors)

VCS

• UI improvements around conflict resolution

MPS-extensions

• diagrams: to support custom SVG export, the SVGGenerator class is now an object with options (TextAsShape, UseCSS, SetViewBox).
• rich text: Generic placeholders like generic comments can’t be inserted into words anymore (an exception was thrown).
• tables: Prevent inserting a new row node before/after a singular cardinality child node

mbeddr

An exception was fixed in the mpsutil filepicker.

IETS3 Opensource

KernelF

• Physical units:
  • The units Joule, Coulomb and Watt can now have also prefixes with negative metric scaling, e.g., mW (milliwatt). Additionally, some typos have been corrected in the physical units documentation.
  • The precision of number types with prefixed units (e.g. mW or km) was always set to infinite by the typesystem. Now, the precision is as precise as possible.
• ShortLambda Interpreter: Fixed a bug which resulted in a RuntimeErrorType when interpreting ShortLambdas.

Variability

• Viewer for skeleton trees has been improved (better error reporting, more stable, does not break on nodes which are string literals).

specificlanguages/mps-gradle-plugin

I have finally released version 2.0.0 of the plugin, after replacing the buggy artifact transforms with a custom caching solution. A few days later, I released version 2.0.1 which improves compatibility with Gradle configuration cache.

My goal now is to improve the plugin so that it can be used for the build of mbeddr. The main missing features are 1) dependencies on other subprojects and 2) sharing external libraries among several MPS projects in the same repository.

In this new version I have incorporated all the experience I got from setting up builds of MPS projects for customers. Version 1 of the plugin relied heavily on conventions, but I quickly found that, while the idea is compelling, conventions can only work for very simple projects at present.

Therefore, in the new version the build author has to specify the structure of their project explicitly. In exchange, the plugin now supports multiple MPS build scripts, including tests, and even having multiple MPS projects built from a single Gradle project.

Why use the MPS Gradle plugin? There are two main reasons, describing the builds on a higher level of abstraction and staying up to date with the current Gradle best practices for writing build scripts. Writing build scripts on a higher level helps with their maintenance, and Gradle rewards well-written scripts with performance optimizations.

Many build scripts of MPS projects were cobbled together by copying existing scripts from other projects without giving much thought to abstractions. This is mainly because the build scripts were quite complicated to begin with, but this became a vicious cycle with the copied build scripts becoming even more complicated and more and more difficult to maintain over time.

With mps-gradle-plugin, you list the build scripts and their dependencies, and the plugin registers the necessary Gradle tasks. The tasks that the plugin registers are more granular than what build authors would write themselves. This helps potentially avoid more work and have builds complete faster.

Using modern Gradle practices such as lazy configuration and configuration avoidance improves build performance further by avoiding unnecessary work. In addition, although not implemented yet, lazy configuration will enable build and configuration caching, potentially further improving build performance for complex projects.

And there are some convenience features as well. The plugin will:

• generate build scripts for you, so you don’t need to maintain a separate ‘build all scripts’ build script,
• cache MPS and JBR for all subprojects within a single project, and optionally across multiple unrelated projects, so that you don’t have a dozen separate copies of MPS lying around,
• configure MPS to put its cache and log directories in different locations for different tasks so that several MPS instances can run in parallel without stepping on each other.

The new version is already in use in the build of MPS-extensions and I encourage you to try it out on your projects.

MPS master (version 2026.1)

• Fix for Java stubs being loaded incorrectly sometimes (MPS-39316, also in 2025.3), along with a few improvements to Java stubs (MPS-39356).
• Support for multi-line binary expressions (MPSSPRT-474, not accessible publicly).
• UI color fixes and a new splash screen (MPS-39266 - editor gutter color, MPS-39257 - red color in dependency analyzer tool for the Islands theme, MPS-39370 - the new splash screen).
• Migration listeners were changed from extension points to ModuleRuntime.Extensions (a newer way of implementing extensions with an API that is supposed to be more safe in the face of reloading classes).
• Accommodating the updates of the underlying IDEA platform: fixes related to the product-info.json file, RCP boot classpath, converting a component to a service.
• The HTML page that appears when opening a node by URL now shows international characters in the node name correctly (MPS-39352).
• (Ongoing) Updating the generator_demo sample project to the current best practices (ongoing, MPS-39192).
• (Ongoing) integration of the MPS in-IDE build with JPS (the IntelliJ Platform build system). This should help with implementing a background build in the future. MPS used to be able to build in the background, but this option was disabled because with newer MPS versions it led to deadlocks.

MPS-extensions

• Line numbers are now updated asynchronously for better performance
• The assertions of the ‘compare’ language can now be configured to ignore annotations (as they previously did by default).
• An experimental extension point for customizing concept aliases. This feature is implemented using MPS internals and can break in future MPS versions, but you can try it out and give feedback.
• An extension point to customize intentions (e.g. disable intentions from libraries or change their descriptions). Works with the custom intentions menu.

mbeddr

No changes except integrating the MPS-extensions updates above.

IETS3 Opensource

• Improvements in feature modeling. I do not have enough knowledge to describe them or comment on them.

• The typesystem rules now use nullable ‘as’ casts instead of strict (’:’) casts and KernelF should produce fewer exceptions in unforeseen cases.

mps-build-backends, mbeddr/mps-gradle-plugin

No changes in December.

specificlanguages/mps-gradle-plugin

No changes in December.

The artifact transforms story from November turned out to be more complicated. As pointed out by Sascha Lißon, artifact transforms will not let users share MPS or JBR versions among unrelated projects. The key under which the result of an artifact transform is cached takes into account the complete classpath of the Gradle build script that performs the transform (not just the classpath of the transform itself). This classpath depends on the set of applied plugins and their versions and is likely to be different for different build scripts.

IntelliJ Platform Gradle Plugin hit this problem as well and solved it by implementing its own caching of the extracted distributions. I am almost finished implementing this for the MPS Gradle plugin and I’m going to release the final version 2.0.0 soon.

I list changes on master/main branches only. Some, but not all, of these changes are backported to older versions as well.

MPS master (version 2026.1)

IDE

• Update to the latest IDEA platform.
• Various minor UI improvements. For example, an annoying bug where the project pane selection would jump to the ‘Transient Models’ on every build (if transient models are enabled) was fixed.
• UI performance improvements.

Version Control

• Merge driver improvements (‘do not generate’ flag is now merged properly).
• Merge UI improvements.

Generator

• An initial implementation of conditional generation (MPS-38762).

Editor

• Intentions are now enabled on read-only cells (MPS-33716)
  • This should make the corresponding hack in MPS-extensions unnecessary.

Java

• Javadoc improvements:
  • The javadoc language now uses the text language for its text content, including text in various tags such as @param or @deprecated.
  • Text can now be pasted ‘as Javadoc’ (in addition to ‘as Java statement’ and ‘as Java class content’).

Building and Packaging

• All JARs from mps_home/lib/modules are added to the IDEA layout, making the MPS.ThirdParty module in MPS-extensions unnecessary (the module was removed as a consequence, see MPS-extensions changes below).
• MPS build scripts now have a property, mps.log.dir, that can be used to specify a directory where logs will be written, so that they are not written into the MPS home directory. This allows using one MPS installation in multiple parallel builds.

MPS-extensions

Based on the changelog and commit logs:

• Tables: copy-paste support for tables was added.
• Diagrams: there is now a flag to suppress autolayout-on-init functionality, useful when laying out multiple diagrams in a batch.
• Improvements to spell checking functionality (support for custom dictionaries).
• MPS.ThirdParty solution with stubs of libraries bundled with MPS was removed, MPS.IDEA or MPS.IDEA.Modules can now be used instead.

mbeddr

Based on the changelog and commit logs:

Assessments

• Performance improvement when updating results of previously run queries.
• A new option, ‘always show checkboxes’, to let users check off individual entries without marking the entire containing assessment with an error.
• API change to make the current MPS project available in assessments and assessment scopes.

Action Filter

• UI fixes to make sure the selected action profile stays selected after a restart.
• Filtering now works without having to install an IDEA plugin.

Small improvements

• The search tool has got a new icon to distinguish it from the built-in Find Usages tool window.
• CommandButton#perform got an overload accepting the current project as a parameter.

IETS3 Opensource (KernelF)

Based on the changelog and commit logs. These changes are only present on the MPS 2025.1 branch and haven’t been merged to master yet, but hopefully will be soon.

Added

• The Maven POM now contains all bundled JARs as dependencies with provided scope to help with automated license and vulnerability scanning.
• The Grammar Cells of KernelF editors can now be customized through the extension point EditorCustomization. Optional cells, flag cells, constant cells, substitute cells and side transformations can be customized (activation of substitutions, side transformations, description text, post-processing

Fixed

• NumberLiteral editor no longer breaks if a property macro was used for its value.
• Added missing support for IndexExpr for the operations findFirst and forEach.
• Some editor action descriptions were improved.

mps-build-backends

Added support for the current MPS master (2025.3/2026.1). This required passing an additional --add-opens flag to the JVM when launching MPS and making the remigrate backend (for executing re-runnable migrations) properly wait until MPS is done building its indices.

mbeddr/mps-gradle-plugin

No changes in November, but I am working on a simple change to bump the dependency on mps-build-backends launcher from above. However, this leads to dropping support for older MPS versions, at least in tests.

specificlanguages/mps-gradle-plugin

I wanted to release the final version 2.0.0, but unfortunately my clever use of artifact transforms to share a single MPS installation among multiple projects got derailed.

Gradle 9.1 has begun checking the transformed artifacts to make sure they are not changed after transformation, and since MPS likes to write its logs into its home directory, we did not pass the check. JetBrains has implemented a fix for this issue, but the fix did not work correctly on older MPS versions. So now I am waiting for the fix to the fix to be released and hoping that I will not have to implement a workaround.

Proper continuous integration of platforms

I wrote this:

I want to set up proper continuous integration of MPS with mbeddr platform and IETS3 (KernelF). The main/master branch of each library should be regularly built against the latest successful build of MPS master branch. If we can build them regularly, it should be easier to pinpoint compatibility problems because the delta from the previous working build will be smaller.

And I have succeeded in bringing MPS-extensions and mbeddr to build against the master branch of MPS. I haven’t yet implemented this for IETS3 but Alexander Pann is currently working on that.

This required a few bits and pieces:

1. Repackaging and uploading MPS prereleases (this was already available in January).
2. Cascading merges from branches for older versions of MPS to newer versions (also available in January).
3. Automating migrations and running them from the command line as part of the build, in order to make sure that no migrations are pending nor outdated concepts used after the cascading merge.
4. Setting up Dependabot, and later Renovate, to regularly upgrade the used MPS version (and other dependencies).

After all the above pieces were in place, we could change the master branch of MPS-extensions and mbeddr to build against the MPS prereleases.

Tightening the integration checks

Here is what my goal was:

While simply building a project against the latest MPS version will show some problems, it is also necessary to do more automated checks. The CI builds should also check the projects for any deprecated code, code that wasn’t migrated to the latest version of a language (this is likely to happen due to cascading merges) or other violations. Daniel Ratiu’s mps-qa library provides “linters” with most of these checks, as well as whitelisting mechanisms in order to improve the quality gradually, and I am going to look into adding these linters as part of the build for each library.

My vision here was not only to run migrations, but also to check the project for any new deprecated code that was introduced (or code that became deprecated with the new MPS prerelease). I have looked at mps-qa and while it is a very useful library, I found several things I disliked about the approach:

1. I would like to keep the “whitelist” of deprecated code that is currently in use in a text file rather than in an MPS model because I would like it to be human-readable and easy to diff/blame/annotate with Git.
2. I would like to improve on error reporting and I feel that using mps-qa would make it impossible by design because mps-qa integrates into the model checking framework of MPS.

I have prototyped a tool to produce a deprecation report in a YAML-like format but I haven’t implemented it in any projects yet because of limited time and will.

Achievements and new problems

Having the continuous integration with MPS master has helped us to quickly migrate to MPS 2024.1 and will likely help with the migration to 2024.3 as well.

However, as is often the case in software development, solving one problem creates multiple new ones. After automating cascading merges, dependency upgrades, and migration checks, we now have the problem of having many PRs.

We have improved this somewhat by enabling auto-merge for cascading PRs so if there are no migrations necessary, they will be merged automatically as soon as the build is green. But some PRs require mindless but nevertheless manual changes to merge. For example, in a recent version of MPS the format of module descriptors changed slightly so that the order of attributes in a certain XML elements got reversed. This of course produces errors when trying to merge pull requests from the previous version into this one.

A solution to this would be to run migrations automatically on a PR and committing changes. This would immediately “unlock” a new problem: what if a migration is written incorrectly and running it a second time produces more changes? We would need some kind of protection against infinite loops.

Another problem is that there are now several projects for which regularly PRs are being submitted to upgrade them to newer MPS versions, and it is becoming difficult to keep track of the state of all proposed PRs and regularly merge them. A dashboard (and enabling auto-merge for Renovate) would help here.

Incremental builds and modularizing the platform libraries

These were my ideas back in January:

Incremental builds

As more and more checks will be added to the build, it is going to become slower. In order to mitigate this, we will have to look into making the build incremental, so that only affected parts are rebuilt. (Of course, a new MPS version will likely mean that the entire library has to be rebuilt, but a change in one component of a platform should not require rebuilding and reanalyzing unrelated components.)

I have already had some success and gained some experience with incremental builds in a client project but adding incrementality requires providing more information about the dependencies (inputs and outputs) of a particular component from MPS to the build tool. MPS already keeps project information in two places: the .mps directory and the MPS build scripts, and we would be adding a third, so this needs some thinking and automation.

Modularizing the platform libraries

I hope that by improving the tooling around incremental builds, it will also be possible to split the current MPS platforms into smaller components. It is currently impossible, for example, to use just the assessments framework from the mbeddr platform without bringing along most of the rest of the platform. My inspiration here is Spring Framework which is releasing multiple libraries that can be used together but do not have to.

The biggest obstacle to achieving this currently is that this would mean lots of small build scripts, both in MPS and in Gradle, and I would like to avoid having to keep them all in sync. This may also need some changes in the way MPS build scripts describe dependencies (as they cannot handle transitive dependencies very well, for example).

I haven’t made any progress on that, unfortunately. I have an idea to try: reading MPS module descriptors (.msd and .mpl files) to find out the dependencies of each individual module, then leverage Gradle’s support for incremental and parallel builds in order to build modules in parallel, but I’m afraid that modelling Gradle dependencies to match MPS is going to be very tricky, so it’s something that will have to remain a dream for now.

Another problem that would need to be solved is specifying plugins and plugin dependencies. In fact, this is currently the one problem for which the MPS build language offers a unique solution that would be more difficult to replicate outside of MPS. One could create a DSL in Gradle to specify plugins, their contents and dependencies, but checking them for correctness would require knowledge of the plugins bundled with MPS.

Plans for the next year

At the end of the year I can’t help feeling quite exhausted from the build-related work. I feel like it’s important yet at the same time I don’t see anybody else recognize the importance of having a frictionless build and join my efforts. This has led me to gradually spend less and less time on the builds, and in the next year I will likely prioritize writing articles over improving builds.

Why avoid cyclic dependencies

Apart from “soft” reasons such as being confusing and making it more difficult to understand the project structure, cyclic dependencies cause several practical problems when building MPS projects.

First, there is the performance aspect. MPS has to build modules that form cyclic dependencies together in one “chunk”. This means that every time there is a change in one of the modules, all of them will have to be rebuilt.

Second, occasionally the dependencies in the cycle have to be generated in a certain order. For example, a language may have to be generated after the language that it extends due to some aspects using cross-model generation and requiring checkpoints of the extended language to be available. MPS tries to accommodate this and order dependencies in a certain way but it may fail to produce a buildable order.

Third, if your dependencies are forming a cycle that requires you to specify the bootstrap flag in your build project, this is a sign that you are going to have problems building your project in the future. In order to build projects that contain bootstrap cycles, it may be necessary to add the generated sources to source control. It is then easy for these sources to get out of date and this introduces an additional source of friction to the development process.

How to avoid cyclic dependencies

On the day-to-day level, cyclic dependencies often occur when a language grows large and internal logic is extracted into a separate solution (often named generically “helper” or “util”). Care must be taken to ensure that this solution does not depend on the language. A helper solution for a language must not refer to or use any of the concepts defined in the language.

Note that such a solution does not need any special designation. It does not have to be a plugin solution nor a runtime solution, a plain solution with no special settings is enough.

Another source of cyclic dependencies that I have seen is splitting large languages according to “topics”. Let’s say, your domain is describing rules and levels of adventure games. As it grows large, you may decide to split the game language into a language for describing spells and another language for describing monsters.

However, although such topic-based split may look natural and logical (after all, we create a separate language for each domain), it will easily lead to circular dependencies. Let’s say, you need to give the user a possibility to describe how a spell affects certain monsters. This leads to a dependency from lang.spells to lang.monsters. Now, let’s say the user wants to describe that certain monsters may use certain spells during combat. This requires a dependency from lang.monsters to lang.spells.

In order to avoid such dependencies, it is important to create a core language which defines the domain objects in the game that need to know about each other. In our case, this language would contain both Monster and Spell. Additional languages may then be created to define additional features, such as complex rules about how spells affect monsters, or conditions for monsters to use spells.

Of course, this problem may also be solved differently with more levels of indirections or abstractions, such as only defining some sort of Rule class in the core language which would affect RuleObjects, and then have Monster and Spell contain Rules which affect RuleObjects, or something in that direction. But this only proves the point: the core language remains, only now it defines Rules and RuleObjects.

Therefore: on a higher level, organize your projects as “core and extensions” where the core defines interfaces, abstract concepts, or extension points for extensions to implement or extend.

When cyclic dependencies do not matter

Cyclic references, especially in user models, do not need to be problematic per se. As a real-life example, we have Wikipedia articles which may refer to each other and form cycles, and this is of course a valuable feature. Notice, however, that I used the word references here. In fact, the problem starts when references turn into dependencies, usually for technical reasons, such as needing to generate and compile Java code.

If all you do with user models is generate some sort of non-executable output such as XML or JSON or HTML, the cyclic references do not need to be a problem.