CUBA goes open source with a handful of features
CUBA 6.1 has received a fair amount of features and due to the fact that this version is the first open source release, here’s a quick overview of what has changed.
It’s been a while since CUBA Platform released a minor version of the platform. So, I was curious about what 6.1 would bring to the table. Let’s start with the first and most straightforward topic: the license change.
From now on: Open source with Apache
With CUBA 6.1, the platform is no longer under a commercial license; instead, it is now under Apache 2 license. Some of the features remain commercial though.
This is a fairly large shift and I think it’s worth noting. Since going from a license where the customer has to pay per running instance & entity quantity & concurrent user to a model where the base variant is free and the commercial part is based on a developer fee, the mindset shift is quite heavy.
But this is only the first part. The CUBA team also opened the development process, which has been explicitly announced on their website:
The source code of the platform is also available on GitHub. We encourage developers to submit pull requests to contribute to the CUBA Platform development.
My personal opinion is that even though commercial developer tools have their place in the world of software for developers, it is quite limited. This is especially true because of the rise of open source software in the past few years.
Due to the fact that software developers are most familiar with the concept of open source, it’s not surprising that the acceptance for open source is most prominent in this area. Or, to put it the other way around: developers’ willingness to choose non-open source software tools decreases from year to year.
When you look at the size of the CUBA community that was created for the English-speaking world, you realize that this observation is not far-fetched.
This all leads to a moment when, to my mind, going open source makes a lot of sense. The amount of potential users will increase dramatically and perhaps there will be contributions from the community that will push everything forward.
After adding my two cents to this topic, let’s dive into the technical changes. I will just go through some of the features from the 6.1 release, as well as the 2.1 release of CUBA Studio. If you want to get information about all the changes, read about the 6.1 release and the studio 2.1 release.
Built-in Groovy support
The first thing I discovered was the built-in groovy support in studio 2.1. When you have a look at the project properties, you can activate Groovy support.
After doing this, when you create a screen or a service, studio will ask you about the language for generation. It’s a bit more convenient than the solution I described in the blog post about Groovy and CUBA.
But it’s a little more limited as well. I’m not aware of how you can create Controller classes, as well as Services in Groovy. Enums, Entities and Entity listeners are created in Java. But this doesn’t seem to be a a big deal, because the template approach from the other post still works. So it’s up to you to customize it depending on your needs.
Custom UI elements
One thing that has not been that accessible in the past was how to customize the UI in a way that you can use custom elements. Before, it was possible to pull in Vaadin add-ons to get around that or if a really custom UI was required, to create some hand-crafted UI in the portal module.
I will not go through all the details in here, but to give you a brief impression of what is possible, here is the JS example from the docs:
Generate models from existing databases
The next thing that got my attention is the ability to create an application from an existing database. This is a very interesting approach when you already have a application up and running with a “reasonably normal” database structure. The existing application can be a Java application but it clearly does not have to be one.
Studio will guide you through a wizard that will read the structure from the database you configured in the project properties. During the process, you can adjust the mapping from the database to the generated models.
To get an idea about the model generation wizard, you can try the following:
- Download HSQLDB sample database
- Create a new project from studio
- Run the server so that the automatically-defined HSQLDB can start
- Connect to the database with a generic database tool like the embeddedDatabaseManagerSwing from HSQLDB or the IntelliJ IDEA Database Connection tool
- Execute the downloaded SQL script on the database
- Start the Model Generation from Studio (Entities > Generate Model)
After doing so, you will see something similar to the image below. The wizard has a few steps to adjust the mapping, generate screens and finally see and adjust the database migration scripts.
Deploy to cloud services from studio
A pretty cool thing is the ability to directly deploy CUBA applications to cloud services.
When you have a look at cloud provider settings, you will see some basic information to login. As I looked through the provider picker, I didn’t know any provider from the list. It turns out that the list contains implementation providers for Jelastic Cloud, where you can select different providers (all run Jelastic in their datacenter).
Jelastic is probably not the most obvious choice when the label is “Cloud deployment” in a market of big players like AWS, Azure or Google. But I think it is definitely a step in the right direction and I personally want to give Jelastic a chance. That being said, there are a lot of possibilities in the cloud path for CUBA Studio and I’m looking forward to what comes next in terms of cloud integration.
API for entity graphs export/import
In order to import or export data, it is now possible to use JSON files as the way to go. TheEntityImportExportService interface allows you to do exactly this.
You can also find a UI for this feature in a number of screens, for example the Entity inspector screen, where you can import or export arbitrary data right out of the box.
If you would like to embed the same feature in the workflow or screens you created by yourself, you can have a look at GroupBrowser for a running example.
Row-level security constraints updates
The last thing that is quite important in the new release is row-level security. There has been row-level security before (as I described in the CUBA security blog post), but with the new release it has become much more comprehensive.
In the first blog post, where I talked about the security aspects of the system, one example I gave was:
Managers in TX (Headquarter) see all customers from all locations, but cannot edit them.
It turns out that at that point in time, CUBA could not really do it. With the new possibility of creating constraints with Groovy, this exact feature can now be achieved. I’ll give you an example in the next security blog post, so stay tuned.
To wrap up, I think there are a few very cool features packed into this release. The license change is probably the most important one.
So I encourage you to play with the changes. Just go to the download section and start from there.
This post was originally published on the Road to CUBA and beyond… blog.