The download link is broken on: Modelling Tools – openehr.org
Can you please point out to the latest version installer (Windows and MacOS)
1 Like
I spoke to @Pete_Bouvier about this. I have a very old MSI installer locally but I’d not trust it and I’m not sure theer ever was a MacOs installer. @thomas.beale might know more but I don’t think we have safe links for installers right now.
I had latest setups (windows) of all old tools but just deleted em last week! It would be good to have them all on the website
I see you VP… 
1 Like
Luckily is still available on the internet archive
1 Like
I have only a Windows installer. There is a lot of extra capability in the tool actually, that I put in while in the US. Wasn’t my choice to do it in that code base, but it serves as a great resource in our current times of AI-based re-engineering.
Anyway, what I discovered while working on the old ADL WB is that making it work on the Mac is only doable by running under Windows under Parallels (works well if you already do that for some other reason, but a pain if you don’t). On Linux it does run, but the anomalies in GTK2 implementation mean that it is visually clunky.
I have major parts already re-engineered in Kotlin now, including BMM4 compiler and Antora website generator, with other code generators coming soon. I’ll have full ADL/AOM functionality soon as well, and then a visual front end will be coming. That’s a little way off but we’re getting there. It will run by default inside IntelliJ (BMM compiler, syntax highlighting all running already).
More soon.
@Pete_Bouvier let me know how / where you would like an installer. For right now it will just need to be a dumb static link on the website, as I don’t have a CI pipeline on that repo (or the time to make it all work for Eiffel, even if I did).
2 Likes
That will be very old!
Thanks Thom. I had a chat with Marcus on Friday and the plan is to overhaul the tools section, so hang fire for now…
Thanks @Pete_Bouvier @thomas.beale and all others. I will admit I’m not completely clear on what tools we have, which ones are still in use, and which are deprecated ‘beyond AI rejuvenation’.
Perhaps we need a bit of an open ‘round table’ on this so we ensure that the great stuff that is in our repos can be salvaged and updated - IF that’s valuable to do. And the stuff which is beyond salvation, we can clearly mark it as deprecated. We need to provide a clear, frictionless path to productive openEHR use for new arrivals to the community, and at present we are presenting what I believe to be a confusing picture:
In particular, the top option is the subject of this thread - it’s Windows-only, we have only old versions of the binary, and from my initial research into Eiffel it doesn’t appear that we can easily compile it for other platforms. CI does not really exist for Eiffel. We might be able to use it as a ‘living spec framework’ for writing something new though…
@thomas.beale is the new Kotlin version in the openEHR repos?
[cc @luis_marco as Chair of @SPB because this probably falls under that remit, to decide what we keep and what we don’t and where engineering effort needs to be applied.]
1 Like
Hi @marcusbaw , spot on! Can’t agree more re: “We need to provide a clear, frictionless path to productive openEHR use“
And Kotlin all the way…I’ve been learning and using Kotlin in Jupyter notebooks (thanks to @christian ) which is pretty cool
We also need to clean and tidy up templates on CKM - quite a few of them are broken and can’t load into a CDR.
1 Like
For what it’s worth, I have made my own backup so the students on my courses can always find an installer: GitHub - ppazos/openehr-modeling-tools · GitHub
1 Like
This is something we have discussed at the Education Program Board: developing a Beginner’ Guide to the basics of openEHR and its ecosystem. Unfortunately, it is currently just an idea, as we are quite limited in terms of time and personnel at the EPB.
1 Like
Thanks @pablo this is a hugely helpful archive, very sensible to have backups of our backups of our backups!
@thomas.beale we could do with a copy of adl_workbench_2.1.0-windows_64bit.exe so we can fix that broken link.
The new Kotlin version will appear in various pieces at maven and in the IntelliJ plugin catalogue and similar (and be automatically built in the proper way on Github). It’s not done yet, and the first versions I release won’t do UI, they’re aimed at enterprise software, BMM programming and so on.
See here on Github for the current release, including binary. Only Windows (or MacOS > Parallels > Windows). I know, it hurts my brain as well, since all my dev machines are Linux these days 
EDIT: ‘current release’ of the old ADL Workbench tool, i.e. the one written in Eiffel 
2 Likes
Thanks Thomas. I’ve asked @Pete_Bouvier to update the link on the website.
One of the first orders of business for the new @SPB is to collate a clear list of what software is available and have a clear ‘Start Here’ for new arrivals to the ecosystem.
2 Likes
Thanks everyone for the updates.
This thread highlights both progress and some structural gaps we should address.
From an engineering standpoint, a few observations:
-
Distribution & Accessibility
The fact that we’re relying on manual sharing indicates a lack of a centralized, reliable distribution pipeline. Critical tools like ADL Workbench binaries should be:- versioned and hosted in a stable release channel (e.g. GitHub Releases or Maven where applicable)
- consistently linked from a single source of truth
-
Fragmentation Between Versions
The transition from the Eiffel based tooling to the Kotlin based ecosystem is understandable, but currently feels fragmented:
- legacy tool (ADL Workbench) still required
- new Kotlin components not yet fully integrated or discoverable
This creates onboarding friction, especially for new developers.
-
Platform Constraints
Requiring Windows for core tooling is a notable limitation in 2026, particularly when many developers are on macOS/Linux. Cross-platform support or containerized alternatives would significantly improve adoption. -
Onboarding Experience
The idea of a “Start Here” is absolutely the right move. Right now, it’s not obvious:
- what tools are current vs legacy
- what is production-ready vs experimental
- how components fit together in a typical workflow
- Recommendation
I’d suggest prioritizing:
- centralized developer portal
- automated build + release pipelines for all artifacts
- cross platform strategy (native or containerized)
- clear deprecation / transition guidance from Eiffel → Kotlin stack
Happy to contribute or help structure this if needed — especially around build/release workflows and developer experience.
1 Like
As far as I know, very few people are using ADL workbench any more (partly because it is not easily portable to the Mac, and partly because it is in a language noone uses anymore, Eiffel). So I have not put in the time to build a modern CI/CD pipeline in Github.
I am rebuilding functionality from this tool and other libraries that were originally re-engineered from it (mainly Archie) into a next generation set of tools, all in Kotlin. Underway
Note that for all modern modelling use, the Better Archetype Designer is the tool you probably want to be using. It is freely available, but not open source.
Other tools developers will want are the various SDKs and vendor tools for template and application building. Some are open source, some are not. It’s a mixed bag…
Understood. The direction toward a Kotlin-based toolchain is a logical and necessary evolution, especially given the declining usage and portability limitations of legacy tools such as ADL Workbench. Avoiding further investment in CI/CD for that layer is a reasonable decision.
However, the current transition phase introduces a degree of fragmentation that impacts developer experience. At present, the ecosystem appears to operate across three parallel layers: legacy tooling, emerging Kotlin-based components evolving from libraries such as Archie, and vendor-specific or partially closed solutions such as Better Archetype Designer. While this is understandable during a migration, it creates ambiguity for new and existing developers attempting to understand the recommended path.
From an onboarding and adoption perspective, the primary challenge is not the existence of multiple tools, but the absence of a clearly defined and communicated “current state.” There is limited guidance on which tools are considered primary, which are transitional, and how they map to specific roles such as modeling, application development, or system integration.
A practical and relatively low-effort improvement would be the introduction of a structured ecosystem overview that defines recommended toolchains by use case. For example, clearly distinguishing the preferred tools for modeling versus development, and explicitly identifying legacy components, would significantly reduce confusion. This type of guidance would not require full technical consolidation but would provide immediate clarity.
In parallel, the ongoing Kotlin-based redevelopment presents an opportunity to establish stronger foundations around distribution, versioning, and modular design. Introducing consistent release practices and a unified distribution approach early in this process would help avoid repeating the fragmentation currently observed.
Overall, the strategic direction is sound, but improving clarity around the transition and providing structured guidance would greatly enhance developer onboarding and ecosystem accessibility.
I agree entirely
At the moment, this is just my own project; but it will be pretty ‘modern’ in terms of Github setup + build automations + issue tracking and so on.