# ADL Workbench installer/download not resolving **Category:** [ADL Workbench](https://discourse.openehr.org/c/adl-workbench/94) **Created:** 2026-04-02 02:57 UTC **Views:** 98 **Replies:** 16 **URL:** https://discourse.openehr.org/t/adl-workbench-installer-download-not-resolving/11902 --- ## Post #1 by @Koray_Atalag The [download link](https://openehr.org/download_files/adl_workbench/adl_workbench_2.0.6-windows_64bit.exe) is broken on: https://openehr.org/modelling-tools/ Can you please point out to the latest version installer (Windows and MacOS) --- ## Post #2 by @vanessap @Pete_Bouvier :slight_smile: --- ## Post #3 by @ian.mcnicoll 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. --- ## Post #4 by @Koray_Atalag 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 --- ## Post #5 by @Pete_Bouvier I see you VP… :eyes: --- ## Post #6 by @yampeku Luckily is still available on the internet archive https://web.archive.org/web/20221110174209/https://openehr.org/download_files/adl_workbench/adl_workbench_2.0.6-windows_64bit.exe --- ## Post #7 by @thomas.beale [quote="ian.mcnicoll, post:3, topic:11902"] 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. [/quote] 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). --- ## Post #8 by @thomas.beale That will be very old! --- ## Post #9 by @Pete_Bouvier Thanks Thom. I had a chat with Marcus on Friday and the plan is to overhaul the tools section, so hang fire for now… --- ## Post #10 by @marcusbaw 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](https://github.com/openehr) 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: ![image|565x500](upload://rvSqbJ3HX5bnbFK6qIkw06Ey9AC.png) 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.] --- ## Post #11 by @Koray_Atalag 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. --- ## Post #12 by @pablo For what it's worth, I have made my own backup so the students on my courses can always find an installer: https://github.com/ppazos/openehr-modeling-tools --- ## Post #13 by @damoca [quote="marcusbaw, post:10, topic:11902"] We need to provide a **clear, frictionless** path to productive openEHR use for new arrivals to the community [/quote] 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. --- ## Post #14 by @marcusbaw [quote="pablo, post:12, topic:11902"] I have made my own backup [/quote] Thanks @pablo this is a hugely helpful archive, very sensible to have backups of our backups of our backups! [quote="thomas.beale, post:7, topic:11902"] let me know how / where you would like an installer. [/quote] @thomas.beale we could do with a copy of `adl_workbench_2.1.0-windows_64bit.exe` so we can fix that broken link. --- ## Post #15 by @thomas.beale [quote="marcusbaw, post:10, topic:11902"] @thomas.beale is the new Kotlin version in the openEHR repos? [/quote] 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](https://github.com/openEHR/adl-tools/releases/tag/v2.1.0.3251) 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 :frowning: EDIT: ‘current release’ of the old ADL Workbench tool, i.e. the one written in Eiffel ;) --- ## Post #16 by @marcusbaw [quote="thomas.beale, post:15, topic:11902"] [See here on Github](https://github.com/openEHR/adl-tools/releases/tag/v2.1.0.3251) for the current release, including binary. [/quote] 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. --- ## Post #17 by @Cozy_Beard Thanks everyone for the updates. This thread highlights both progress and some structural gaps we should address. From an engineering standpoint, a few observations: 1. 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 2. 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. 3. 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. 4. 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 5. 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. --- **Canonical:** https://discourse.openehr.org/t/adl-workbench-installer-download-not-resolving/11902 **Original content:** https://discourse.openehr.org/t/adl-workbench-installer-download-not-resolving/11902