Using Quarkus for Moqui

Community
1

As you probably are aware Quarkus is now really getting popular for the Java based applications.
There is already an initiative moving OFBiz to the Quarkus framework. Could this be something for Moqui too?
I am worrying a bit about moqui about the in- activity here, using Quarkus as the framework for the entity engine and the service engine would make the Moqui system sure more interesting for a wider public.

Iinitiative for Ofbiz: GitHub - jnbdz/SunsetERP: 🌇 SunsetERP 🌇 - RESTful ERP based on OFBiz that runs on Quarkus.

Any thoughts about this idea?

1 Like
2

It seems for most part Quarkus is incompatible with moqui; it may have different architectural goals and designs.

I also had multiple attempts in introducing re-architecture to OFBiz and my expectation is that it is highly unlikely for any such initiatives to follow through. I was able to switch the framework from ant to gradle, and refactored some of the core code, but faced big difficulties going any further due to both community and technical / design problems.

One of the things that I deeply appreciate about moqui is the care for quality, not number of commits. This is a major reason why we shifted our projects from OFBiz to moqui and had success in launching large and successful projects on it.

1 Like
3

Thanks for the reply,
However, I do not know if you had a serious look into Quarkus, a from Redhat sponsored Java framework with more than 1000 contributors and is fully reactive, hot restart and has all that Moqui has, except for the entity, service engine and ftl screens.

could be a nice upgrade pattern…

Regards,
Hans

1 Like
4

What would be the reason for, or benefits from, using Quarkus in Moqui?

The popularity rationale means nothing to me, and while many have stated over time that if we use this or that popular thing it will make Moqui more popular I have never seen anything like that happen, not even with the popular tools selected on day 1, and not with any that have been added. The bulk of the growth in Moqui has come from projects and products based on it, not so much what it is based on (which is helpful in some companies, harmful in others, just depends on their current internal technology preferences).

5

Why?

What are the reasons and benefits of using Quarkus with Moqui?

  1. Reduced size and complexity of the Moqui software, making it easier to maintain.
  2. Enhanced framework support through Quarkus.
  3. Improved tool support, with more editor plugins for Quarkus.
  4. Better integration with Camel, Kafka, and many other tools.
  5. Built-in Kubernetes and Docker support.
  6. Native compilation capabilities included.
  7. Faster startup times, with more processing done at build time.
  8. Support for live coding and running unit tests.

The Future of Moqui

I’m becoming concerned about the current state of Moqui support:

  1. Lack of response to pull requests (I have submitted two with no reply).
  2. No attention to the Java 17 compatibility request.

By leveraging Quarkus, Moqui’s codebase could be streamlined, making it easier for even non-experts in Moqui to maintain.

Proposal

My proposal is to start by making the entire Moqui system compatible as a Quarkus extension.

From there, we can gradually reduce Moqui by replacing functionalities with Quarkus-provided features, retaining only the core Moqui functionalities:

  1. Entity engine
  2. Service engine
  3. FTL UI
  4. ERP system
  5. Data model
1 Like
6

The PR mentioned seems to be switching from JsonSlurper to JsonSlurperClassic, a downgrade to the older version with less performance or standards compliance to make it work with Quarkus.

This might possibly be a reason why it’s not yet merged. This PR seems to favor Quarkus at the expense of using older groovy API.

1 Like