CUBA Platform for Java enterprise application development

What CUBA Platform is designed to build

CUBA Platform targets enterprise web applications written in Java. The repository describes it as a high level framework and, more specifically, as a Java RAD framework whose main interface is rich and web based. That places it between a collection of reusable libraries and a complete application-development environment. The goal is not merely to provide a web server adapter or a persistence helper. It is to give developers a platform around which an enterprise application can be organized.

The clearest documented audience is a Java development team that needs to create a substantial business application without manually defining every application layer and integration point. CUBA Studio is the documented starting point. Creating a new project there automatically downloads a released platform version from the platform's artifact repository. That behavior makes Studio part of the normal application setup path, while source builds and snapshots cover developers who need a version that is not represented by a standard Studio release.

CUBA is therefore most relevant when the application needs the framework's enterprise conventions and generated project structure. A small Java service or a narrowly scoped utility application may be better served by a smaller stack. The repository summary calls CUBA a full-stack framework, but the README does not enumerate every application layer or service included in that label. Its suitability therefore depends on matching the broader platform to the application's requirements, not on assuming that every Java web application needs it.

CUBA Studio, artifacts, and the application boundary

The documented application flow begins with downloading CUBA Studio and creating a project. According to the README, Studio downloads a released version of the platform automatically from the artifact repository. This separates the tool used to create the project from the platform artifacts consumed by the generated build. It also means that setup depends on access to CUBA's artifact infrastructure rather than on copying framework source files into each application.

For a snapshot workflow, CUBA is built into the developer's local Maven repository under `~/.m2`. The application's `build.gradle` then points `ext.cubaVersion` at that snapshot and includes `mavenLocal()` in its repositories. A local Gradle build can consequently resolve the snapshot without making the framework source part of the business application's repository.

Based on the repository layout, the platform itself is a multi-module Gradle build. The top level contains `build.gradle`, `settings.gradle`, `gradlew`, `gradlew.bat`, and a `modules` directory. That structure suggests reusable platform components are developed and installed independently before application builds consume them. The README also identifies forks of EclipseLink, Vaadin, Vaadin Drag and Drop Layouts, and the Vaadin ACE editor. Those libraries are published through CUBA's artifact repository, so normal consumers are not required to build each fork from source.

Building CUBA from source with Gradle

Source builds require Java 8 and the CUBA Gradle Plugin. The plugin is a separate repository and must be built first. The README assumes sibling directories named `cuba` and `cuba-gradle-plugin`, with the terminal opened in their parent directory. Build and install the plugin into the local Maven repository with the wrapper included in that project:

cd cuba-gradle-plugin
gradlew install

After that command completes, enter the CUBA repository and install the platform using its own Gradle wrapper:

cd ../cuba
gradlew install

These are source-maintainer steps rather than a normal prerequisite for every application user. The README states that released dependencies are already available in CUBA's artifact repository, so applications normally do not need to build EclipseLink or the listed Vaadin forks from source. The source procedure matters when developing CUBA itself, testing modifications across its modules, or producing a snapshot for a local application.

The repository also includes Windows wrapper support through `gradlew.bat`, but the README gives only the Unix terminal commands. No install script, service deployment procedure, database setup command, or initial application schema command is documented in the repository excerpt. Anyone expecting a command-only deployment tutorial will not find one here.

Running a first application against a snapshot

The documented snapshot path begins after the source builds have installed CUBA into `~/.m2`. In the application's `build.gradle`, set `ext.cubaVersion` to `7.3-SNAPSHOT` and add `mavenLocal()` to the repositories available to `buildscript`. The README excerpt shows the beginning of that configuration rather than a complete file, so it should be treated as the required fragment, not copied as a complete Gradle build.

buildscript {
    ext.cubaVersion = '7.3-SNAPSHOT'
    repositories {
        mavenLocal()
        maven { ...

The ellipsis is present in the README and is not a complete repository declaration. An application owner must preserve or complete the surrounding Gradle configuration according to that project. Once the snapshot is resolvable through the local Maven repository, the README gives `gradlew deploy` as the build and deployment action:

gradlew deploy

This is the closest documented first-use path from the repository text. It does not explain what CUBA Studio project template to select, how to start CUBA Studio after installation, which application task is generated, or how to confirm a running web interface. Those details must come from CUBA Studio documentation or the official documentation linked by the repository.

Dependencies, licensing, and upgrade work

CUBA Platform is distributed under the Apache License 2.0, as stated in the repository description and represented by the README license badge. The repository includes `LICENSE.txt`, so users should review that file together with the licenses of dependencies resolved into their application. The presence of an Apache 2.0 project license does not by itself establish the exact licensing status of every runtime or build dependency.

The platform's dependency model is material to adoption. CUBA uses forked versions of EclipseLink and several Vaadin components, and the README directs source builders to separate repositories for those forks. Released builds can obtain them from the CUBA artifact repository. That creates a controlled artifact path, but it also means source builds require the plugin-first sequence and local artifact installation shown above.

The repository is not archived, and its last push was on 2026-09-22. No GitHub releases are present in the repository record, even though the README refers to a download page and released platform versions. The README does not document version migration, rollback, compatibility matrices, or the number of artifacts that must be reviewed during an upgrade. Consequently, upgrade cost cannot be reduced to a version-number change. It includes checking framework compatibility, application configuration, and any separately published third-party artifacts.

The absence of GitHub releases also creates a source-selection issue. The repository can contain development work on its `master` branch without serving as the complete release history. The README's `7.3-SNAPSHOT` example is specifically a local snapshot workflow, not evidence that `7.3-SNAPSHOT` is the current or supported production release.

Where CUBA differs from manual framework assembly

The practical alternative is to assemble an enterprise web application manually with Gradle and the required Java libraries. In that approach, the developer chooses and configures each dependency, creates the application structure, and resolves compatibility between components. CUBA instead presents a higher-level framework, an artifact-backed platform version, and CUBA Studio as the documented project creation path.

That difference is meaningful when a team values a predefined enterprise structure. Manual assembly offers direct control over component selection, but the README does not claim that CUBA can reproduce every possible Gradle or Java application design. CUBA's abstraction can also become a constraint when its module conventions, supported configuration, or released artifact set differ from an existing application's architecture.

CUBA is the wrong choice if the objective is merely to expose a small HTTP endpoint, avoid a framework lifecycle, or keep every dependency choice visible in `build.gradle`. It may also be the wrong choice for a build pipeline that cannot access CUBA's artifact repository or that forbids locally installed snapshots. Based on the available documentation, the decision should start with whether Studio, the platform artifact model, and the framework's enterprise structure solve a problem the team actually has.

Editorial conclusion

CUBA Platform is a reasonable fit for Java teams building enterprise web applications and accepting its framework conventions and artifact distribution model. It is a poor fit when the repository must be built independently without the CUBA Gradle Plugin or when a lightweight application would carry more framework structure than needed. Before adoption, check the documentation for the released platform version, verify the required JDK and plugin setup against the current build files, and determine whether the application's runtime and upgrade requirements fit the selected CUBA release.

Frequently asked questions

Official sources

1. cuba-platform/cuba on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README