Angular Nuxeo UI and the Maretha Software Factory Behind It

A modern Web UI for Nuxeo has been on my mind for a long time.

It was on Nuxeo’s roadmap in 2019, before I left the company and started Maretha Solutions. Since then, it’s been the thing our clients ask for most. We wanted to build it, too. Finding the time was the hard part.

Today, we’re releasing Maretha Angular WebUI as open source: a new interface built on Angular 21 for Nuxeo LTS 2025.

The code: https://github.com/maretha-labs/maretha-angular-webui, under the Apache-2.0 license.

Our work with LLMs finally gave us the capacity to take this on. Along the way, we built a process for planning, writing, reviewing, and testing the code they produce. We call this our Maretha software factory, and much of what makes it useful ships with this release.

That deserves a little explanation.

We start by working through a plan with an LLM before writing code. We give agents specific jobs and the context they need, then have them write unit tests and implement the approved plan. A review agent examines each change. We test the running application in a real browser and add functional tests to cover the behavior we’ve checked.

Every pull request then goes through continuous integration. If a required check fails, the change doesn’t merge.

Our team sets the direction, approves the plan, and decides what counts as done. We can step in and evaluate the agents’ work at any point. The process helps a small team apply that judgment consistently across more work than we could review by hand.

Maretha Angular WebUI is one of the projects we’ve built this way. Given how long our clients have wanted it, we decided to make it fully open source.

Nuxeo’s existing Web UI is built on Polymer. The Polymer project’s own README has recommended LitElement for new development since Google I/O 2018. For teams with years of customizations invested in that UI, moving forward means dealing with everything they’ve built around it.

We’ve tried our best to make that move practical.

The Angular UI installs as a standard Nuxeo LTS 2025 package and runs at /nuxeo/ng/ (or whatever route you define). You install it with nuxeoctl, configure the public URL, and serve it over HTTPS.

All 24 extension slots in Nuxeo Web UI 3.1 have Angular equivalents. We’ve added two more for quick search and shell actions. Document layouts support create, edit, import, view, and metadata modes for any document type. A spreadsheet editor built on the MIT-licensed AG Grid Community is included and enabled by default.

The repository also includes a generated parity document that accounts for each Polymer default: what it maps to in Angular, or whether it belongs to an add-on we don’t ship, such as Nuxeo Enhanced Viewer.

The verification tooling is a substantial part of the release.

Before a commit, a hook runs lint with zero warnings allowed, checks formatting, and runs the type checker. On every pull request, the main verification job runs 20 checks covering:

• Application and test code quality.
• Customization boundaries, generators, and the hash-locked core.
• Translation catalogs and the Polymer parity map.
• Unit tests and a coverage baseline that cannot decrease.
• The production build, public SDK API, and an SDK upgrade rehearsal.

Two additional jobs open the built application in a headless browser. One runs the Axe and IBM Equal Access accessibility scanners. The other checks every supported language, Arabic right-to-left layout, and a pseudo-language used to test localization, in both themes. CodeQL and dependency review run alongside them.

We also test some of the checks themselves. We deliberately introduce defects, such as a broken layout or an SDK regression, and verify that the relevant check catches them. Each run saves reports as build artifacts, giving reviewers something to examine beyond a green status.

There is one limit to the public setup: our critical-path tests against a live Nuxeo server depend on our fixture environment and run on our own runner. The remaining checks run on GitHub-hosted runners for public pull requests, including those from forks.

You can use your own coding assistant to customize the UI.

Claude, ChatGPT, Gemini, Copilot - the repository doesn’t depend on a particular provider. We use self-hosted open-source models for our own work. The repo contains no AI service and makes no model calls; your assistant needs to be able to read the project files and run npm commands.

UI customizations live in custom/. The core files are recorded with SHA-256 hashes in core.manifest.json. If an assistant changes a protected file, verification fails and tells you which one.

Generators give the assistant a useful starting point. One command creates a slot contribution with its component, test, and registration. Another creates layouts for a document type and the modes you need.

Lint enforces the import boundaries and dependency rules. Custom code uses the public SDK and approved dependencies. Hard-coded credential fallbacks are rejected. Generated IDs use the prefix in custom/owner.json, keeping your contributions distinct from the defaults.

The instructions are in AGENTS.md and the agent guides: what context each slot receives, how to order contributions or override defaults, and how existing Polymer customizations map to Angular. For migration work, there are designated locations for your mapping and original Polymer sources.

The aim is to give your assistant enough context to make a useful change, and give you a reliable way to check its work.

That matters because of a situation we see often with Nuxeo projects. The person responsible for the business outcome knows exactly what needs to change. Getting it changed depends on a developer, a vendor, or the one person who still remembers how the customization bundle works. A small improvement can spend weeks waiting in a queue.

We want to make those improvements easier to attempt, review, and maintain.

Maretha maintains the core. Your team controls its customizations, which remain in your own copy of the project. Upstream contributions to the OS core follow a separate process: product changes need an issue confirmed by a Maretha maintainer, with work on a branch tied to that issue.

For an existing Polymer customization, migration starts with an inventory. From there, you can port each contribution with your assistant and verify the result. We offer migration help and production support for teams that want them.

We’re a Hyland partner. Maretha Angular WebUI is a Maretha project, not a Hyland product.

If you want to try it, start with something small and useful:

• Search your existing Web UI bundle for nuxeo-slot-content to begin an inventory of your customizations.
• Clone the repository and ask your assistant to add one action your users have been requesting.
• Run npm run verify and review the result.

If that change requires modifying the core, open an issue and tell us what you’re trying to accomplish. That helps us understand where the extension points need more work.

This project has been a long time coming. I’m glad we can finally put it in your hands and I’m looking forward to seeing what your teams build with it.