Eclipse BIRT: a reporting engine and a report designer in one repository

What lives in the repository, and what the README does not say

Eclipse BIRT is described in one line as the open source reporting and data visualisation project, with the project site at eclipse.org/birt. The README is short, and the top level directory listing carries most of the information about how the project is put together. The listing includes core/, data/, engine/, chart/, model/, UI/, features/, viewer/, nl/, xtab/, tutorial/, testsuites/, docs/, build/, promotion/, copy-settings and a pom.xml, plus a Jenkinsfile, a runCBI.sh script, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, NOTICES and a LICENSE.

The directory names describe the structure better than any summary would. A core/ and an engine/ are the runtime side, data/ is the data handling, chart/ is the charting, model/ holds the report model, UI/ is the designer, features/ is the OSGi feature packaging, and viewer/ is the web viewer. nl/ and xtab/ are the translation and cross tab pieces, and testsuites/ and tutorial/ are where the tests and the teaching material live.

The two halves matter for a decision. BIRT is both an authoring environment and an execution engine, which is why the repository carries a designer as well as a runtime, and why it is built with Tycho, the Maven build system for Eclipse OSGi projects. An organisation that wants the report designer and the engine to share a model format, an expression language and a set of connectors is the case BIRT fits. An organisation that only wants to render a chart inside an existing application may find it heavy, and the README does not say much about the size of the dependency, so that judgement has to be made from the modules you actually include.

Building with Maven and Tycho on Eclipse CI

BIRT is built with Apache Maven through Tycho, and the build runs on Eclipse CI. For a developer, the documented build command is short:

    mvn clean verify -DskipTests=true

The build environment is specified as JDK 25 and Maven 3.9.11, and the continuous integration job is at ci.eclipse.org/birt/job/build. Skipping the tests in the local command is a deliberate choice, because the full verification includes the test suites and is a long job on the CI server rather than on a laptop.

For people who want to change the project rather than only build it, the README points at the Create Eclipse Development Environment material, including an Oomph setup file that the Eclipse installer can open directly, and a video of the same process. That matters because building BIRT as a set of OSGi bundles is not the same activity as building an ordinary Maven project, and a development environment that already has the Eclipse platform and the target platform resolved saves a lot of time.

The repository also carries a Jenkinsfile and a runCBI.sh script, which is the older naming for the same kind of continuous integration entry point, and the presence of both reflects a project that has been built in the Eclipse CI environment for a long time.

Releases every quarter and a nightly stream towards 4.26.0

The release history is regular. Version 4.25.0 was published on 2026-09-09, 4.24.0 on 2026-06-10 and 4.23.0 on 2026-03-11, which is a quarterly rhythm that a platform team can plan for rather than react to. The repository was last pushed on 2026-10-13, so work is continuing, and it is not archived.

Getting a runtime is a matter of choosing between the release channels. The current release is available at download.eclipse.org/birt/updates/release/latest, with a version specific location for 4.25.0, and there is a separate nightly location at download.eclipse.org/birt/updates/nightly/latest for the snapshots heading towards 4.26.0. The distinction between the two is the same one every Eclipse project has: the release line is what you deploy, and the nightly stream is what you test against before the next release lands.

The version numbers in the README are slightly confusing and it is worth naming the detail. The section headed Latest Version 4.25.0 points at the 4.25.0 release, while the runtime requirements section says that the current version 4.24 is runnable with JDK 25. Read the two together as the release line moving forward at the quarterly cadence, and check the runtime requirements for the specific version you deploy rather than assuming the newest entry applies to your build.

Tomcat 11 is untested and older lines need an explicit module opening

The runtime requirements are where an upgrade can surprise you. The current line expects JDK 25, which the documentation marks as an LTS, and the supported servlet container is Tomcat 10. Tomcat 11 is listed as untested, with a request to report issues, which is a clear signal that it is not a supported configuration yet.

The pre-4.23 section is the more useful part of the document. It lists the Tomcat 9 lines that were supported, from 9.0.7x through 9.0.10x including 9.0.109, and then records a specific constraint: BIRT 4.22.0 requires Tomcat to be launched with the JVM argument -add-opens=java.base/java.net=ALL-UNNAMED, and that can be accomplished by setting the CATALINA_OPTS environment variable before starting Tomcat.

That is the kind of detail that turns into a support ticket. The failure mode is a report runtime that cannot open a network related class under the module system of a modern JDK, and the fix is not obvious from a stack trace unless you know it is coming. The project links two references for it, issue 2271 and discussion 2278, which is the right place to look for the full context.

The shape of the advice for a new deployment is therefore clear. Stay on Tomcat 10 with JDK 25, treat Tomcat 11 as unproven until the documentation changes, and if you are still on a pre-4.23 line and on Tomcat 9, set CATALINA_OPTS before the first start rather than after the first failure.

Engine only, designer only, or the engine as an embedded library

The most useful distinction inside BIRT is the one between the authoring side and the execution side, because they are separate modules in the tree. The UI/ directory is the report designer, the part a person uses to lay out a report, and it is an Eclipse based application. The engine/ directory is what actually runs a report design and produces output, and the viewer/ directory is the web front end for looking at one.

That split gives you three realistic deployment shapes. The first is a designer on a developer's machine and an engine in a server side application, which is the classic arrangement and the one the OSGi feature packaging in features/ is built for. The second is a designerless deployment where reports are created programmatically or by a reporting specialist using the designer offline, and the engine is all you ship. The third is the engine embedded in a larger Java application, with the reports treated as a library dependency rather than as a separate service.

The choice changes the dependency surface a great deal, and the README does not quantify it, so the honest way to evaluate BIRT is to look at what you actually need from the engine and chart/ and data/ modules, and to leave the designer out if no one at your organisation will be authoring reports in the tool. A containerised deployment that must run the reports in a small footprint is the case where the designerless option is worth the effort of working out the module set.

EPL-2.0, the NOTICES file and what a quarterly cadence costs

The licence is EPL-2.0, with the licence text in LICENSE and a NOTICES file alongside it, which is the standard pairing for a project that bundles third party components. The EPL is a weak copyleft licence, so a deployment that embeds BIRT as a library and modifies those library files has obligations that a deployment using the unmodified engine does not, and the NOTICES file is where the attributions for the bundled components live. Anyone embedding the engine into a commercial product should read both, and should read the version of the notices that ships with the version they deploy.

The maintenance cost is better described as a rhythm than as a risk. Three releases in nine months means an upgrade roughly every quarter, each one bringing a new platform baseline, a new Tomcat line to test and a new set of NOTICES to review. That is manageable for a platform team with an integration environment, and it is a real tax for a small team that has other things to maintain.

The support channels are the Eclipse ones. The project site is at eclipse.org/birt, the code and issues live on GitHub, where the references in the README point at specific issue and discussion threads, and the repository carries SECURITY.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md for the reporting and contribution processes. There is also a tutorial/ directory in the tree, which is where the tutorials on the report model and the design environment live.

Editorial conclusion

Eclipse BIRT fits an enterprise Java shop that already builds on Eclipse OSGi or Tycho, wants a report designer and a report engine in the same stack, and can accommodate a quarterly upgrade rhythm with a runtime pinned to a specific JDK. It is the wrong tool for a team that wants a light dependency, and the wrong choice if you are on a container platform that only supports Tomcat 9, because versions before 4.23 need an explicit module opening for java.net. Before adopting it, read the runtime requirements for your exact Tomcat line, check whether the report engine is enough without the designer for your use case, and review the NOTICES file alongside the EPL-2.0 licence before you redistribute a deployment that embeds the engine.

Frequently asked questions

Official sources

1. eclipse-birt/birt on GitHub
2. License: EPL-2.0
3. Project website
4. README
5. Releases