Hello! I am a Firebird developer, and I work on expanding the Firebird ecosystem, including integrating Firebird with other projects and technologies.
Previously, I submitted PR #5532 to add Firebird support as a primary database for Jmix. The PR was not accepted because officially supporting an additional database would require ongoing testing and maintenance from the Jmix team. During the discussion, I was advised to implement Firebird support as a separate add-on.
Is it okay to publicly share information about jmix-firebird-addon in Jmix tickets, discussions, and on the Jmix forum?
In particular, I would like to clarify:
whether I can share links to the add-on and documentation with users who need Firebird support;
whether the Jmix team has any objections to such a community solution while Firebird is not officially supported by the platform.
I do not want to create the impression that Firebird is officially supported by Jmix. My goal is simply to share a working independent solution with interested users while official Firebird support is not available in the platform.
I would also like to ask whether it is possible to get an additional temporary period of Jmix Studio Premium access. My trial period has ended, and I still need to test the projects and finish the documentation. The subscription would only be used for testing and preparing documentation, not for commercial development.
Overall, I would be interested to hear the Jmix team’s opinion about this work. How do you feel about such a community add-on and about me sharing it with Jmix users? Perhaps you have some comments, questions, or concerns about this approach.
Of course we don’t mind if you share your work, it’s a free forum after all.
We would also be happy to put your add-on on the Jmix marketplace, but let me first ask some questions:
Would it be possible to move the docs to the same github repository as a set of markdown files, to remove the build step?
How do you see the usage of Firebird as a main database if the project includes add-ons that require a database schema?
Regarding Studio subscription, please email us at info@jmix.io with a quick message and a link to this topic.
I would like to clarify what exactly you mean by moving the documentation. Should I completely convert the existing documentation to Markdown and move it into the add-on repository, or would it be better to prepare a shorter Markdown version focused on using the add-on and keep the full documentation in a separate repository? What exactly would you like to see in the documentation? Perhaps I should use the documentation of other add-ons as a reference?
Regarding the second question, if I understood correctly, you mean add-ons that require their own database schema, such as Reports, Audit, and Dynamic Attributes. If so, I tested Firebird with these add-ons.
I added the add-ons both through Jmix Marketplace and manually. When adding them manually, in addition to the Gradle dependencies described in the documentation, with Firebird it is also necessary to manually include the add-on changelog in Liquibase:
This is because Firebird is not supported by Jmix Studio, so Studio cannot run the project through the Run action and automatically add the required Liquibase changes when the add-on is connected manually.
When adding add-ons through Jmix Marketplace, the required changes are added automatically, and the add-ons work successfully with Firebird.
So far, I have not found any limitations when using Firebird with such add-ons.
The add-on documentation is now available as Markdown files in the add-on repository, alongside the source code, and does not require a separate build step. It covers installation, configuration, Jmix Studio limitations, and troubleshooting.
Please publish the add-on binaries to Maven Central or to your GitHub repo as described at Publishing an Add-on :: Jmix Documentation
Then we’ll be able to add the add-on coordinates to the BOM and publish it on the marketplace.
I saw the add-on in the Marketplace. I had just been following the GitHub issue related to this add-on, which is still open, and I assumed it would be closed once the add-on was published in the Marketplace: https://github.com/jmix-framework/jmix-website-content/issues/82
I have a few questions regarding installing the add-on through the Marketplace.
The description says that Jmix 3.0 is supported, but in the Marketplace inside Studio the add-on is only available starting from Jmix 3.0.2.
Also, when installing it, Studio only adds the starter and an include to the Liquibase changelog. However, the add-on include is placed after the changelogs of the Jmix modules, while it should be placed before them. To work with Firebird, you also need to manually add the JDBC driver and adjust the application’s initial migrations, in addition to configuring the database connection.
Am I correct in understanding that this is the expected behavior and that installing the add-on through the Marketplace does not replace the manual steps described in the documentation?
If so, perhaps it would be worth explicitly mentioning this in the add-on description and noting that the documentation should be followed for the complete setup. This would help avoid giving users the impression that after installing the add-on, they only need to configure the database connection.
I can propose changes to the description myself via a PR, but first I’d like to hear your opinion on whether it should be explicitly stated that installing the add-on through the Marketplace does not perform all the required steps automatically, and that additional steps from the documentation are needed to fully configure Firebird support.
I think you should add all details about the installation process to the add-on’s README. Then we’ll mention those details in the marketplace description.
