Thanks Jacopo,
Sounds wise to me
Jacques
Le 30/10/2025 à 09:06, Jacopo Cappellato a écrit :
Hi all,
It's great to see there are valuable ideas and perspectives being shared.
I believe it would be difficult to address all the interesting questions
and concerns each of us may have at this stage. It might be more effective
to tackle them progressively, as the community gathers more information on
specific topics and we can take more informed and better-targeted decisions.
Moreover, some (even important) topics may not be directly relevant to the
framework/application split itself, for example, how to organize entity
definitions or how to structure utility classes. These are certainly worth
discussing, but perhaps in a separate context.
Even very relevant questions, such as “where is the dividing line between
framework and applications?” or “which parts of the applications and data
model will belong to the framework?”, might be more productively discussed
as we proceed with concrete steps. When we start working on specific areas
that require modification to achieve a cleaner decoupling, these questions
will naturally become clearer. And of course, our view on aspects like the
“dividing line” may evolve as we gain a better understanding of the system
along the way.
With that said, I think it is important to start this effort now, keeping
as our guiding principles the core software design concepts of high
cohesion (within components) and low coupling (between components). I
believe we all agree that these principles would be beneficial. OFBiz was
originally designed as a composition of various components (both framework
and applications), but, unfortunately, over time their internal cohesion
has decreased and their coupling has increased. Starting to move back in
the opposite direction, even gradually, seems like a desirable and shared
goal.
We can defer some of the higher-level decisions, such as whether we’ll end
up delivering two separate products (e.g., OFBiz Framework and OFBiz
Applications), one combined product, or multiple specialized distributions,
as well as which tools and workflows we’ll adopt to support contributors
and users. These are important questions, but they don’t necessarily block
us from reorganizing our codebase according to the principles mentioned
above.
In summary, I’d suggest we begin with small, concrete steps to improve
separation and organization, addressing specific issues as they come up. If
at some point we find that too limiting, we could still consider a more
revolutionary approach (like a new branch for a “next-gen” framework), but
for now I don’t think that’s needed.
Best,
Jacopo
On Wed, Oct 29, 2025 at 12:33 PM Michael Brohl <[email protected]>
wrote:
Hi Deepak,
How can we establish a sound basis for decision-making for the community?
I believe we need a more detailed plan regarding a possible separation
between applications and framework, which addresses the following
questions, among others:
* Where is the dividing line between framework and applications?
* Which part of the applications and the data model will be assigned to
the framework in the future (e.g., logins are required for the framework)?
* How is the data model organized (in my opinion, it should be moved
back to the individual applications; it was outsourced to a separate
component some time ago)
* Can we create a technical option that allows users of OFBiz
applications to configure the framework in order to remain updatable?
* How are Util* classes organized (centrally vs. application-specific
vs. ...)?
* etc.
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 27.10.25 um 08:20 schrieb Deepak Dixit:
Hi Michael,
I’ve created a placeholder JIRA task [1] for the suggested change so that
we can gather all related discussions and information in a single place.
I
don’t want to proceed further if this change is not considered beneficial
for the overall project health.
However, based on my past experience working with various clients and
implementations, I strongly believe this direction could be highly
beneficial for community growth and increased OFBiz adoption.
[1] https://issues.apache.org/jira/browse/OFBIZ-13305
Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org
On Fri, Oct 24, 2025 at 12:23 PM Deepak Dixit <[email protected]>
wrote:
Hi Michael,
Thank you for sharing your detailed feedback,
I completely understand your perspective and agree that OFBiz’s
configurability and the strength of its data model are major advantages.
You’re right that components can be disabled selectively; however,
there are still inter-component dependencies that often prevent fully
isolating or unloading specific modules without impacting others.
This means any customization usually requires patching or maintaining a
separate vendor branch, which complicates upgrades and long-term
maintenance.
My suggestion to move applications out of the core framework isn’t
intended to weaken OFBiz,
but rather to make it more modular and flexible,
enabling users to adopt it as a true framework for building ERP or
microservice-based solutions without being constrained by the default
applications or the 750+ database tables that come bundled by default.
While I agree there are other frameworks available, positioning OFBiz
this
way could increase adoption and community engagement,
especially among teams looking for a lighter and more customizable
foundation.
You’re right that application maintenance could become a concern,
but as we’ve seen, there hasn’t been significant new functionality added
to the default applications in recent years.
Users who want the default apps can still use them, while others could
easily include only what they need, with upgrades remaining unaffected.
We could even consider adding Gradle tasks or scripts to clone or
include
applications dynamically, making customization cleaner and easier to
maintain.
I believe with proper planning, we can find a balance between
flexibility
and maintainability that benefits both framework and application users.
Kind Regards,
--
Deepak Dixit
*www.hotwax.co <http://www.hotwax.co/>*
On Fri, Oct 24, 2025 at 2:18 AM Michael Brohl <[email protected]
wrote:
Hi Deepak,
interesting thoughts although I have difficulties to follow the
reasoning:
If you want to build a custom ERP and don't want to use the default
applications, you can simply configure the system to not load the
applications. Since the datamodel is already decoupled from the single
applications, you can still use the datamodel.
If you also don't want to use the datamodel (which I see as one of the
strength of OFBiz and essential for an ERP system), you can also
configure it to not being loaded (as a whole or for parts of the
datamodel).
I am sceptical if the core OFBiz framework would be adopted as a
framework as there are some strong alternatives out there. In my view,
it ist the framework plus the datamodel, API/services and the
backend/webtools making OFBiz so special.
We are using OFBiz for nearly 25 years now, building complex custom
projects using more or less parts of the datamodel/services and
sometimes even without any UI to serve as a database plus REST API
(using a very much enhanced REST-API plugin). We never had any issues
with "too much functionality" because of the configurable loading
mechanisms.
And the datamodel is always a strong companion when it comes to the
design of business cases because of it's generic design end the
enhancement mechanisms.
So, I do not the any "constraints" preventing anyone from using OFBiz
in
many different ways.
What I see as a potential problem is that the applications will suffer
a
similar fate to the plugins and will no longer be maintained. Some
plugins have even been gradually deactivated because no one wanted to
deal with maintaining them and fixing bugs and security vulnerabilities
anymore.
I honestly would not be happy to see the project going this way.
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 23.10.25 um 14:02 schrieb Deepak Dixit:
Hi Team,
I would like to propose restructuring the OFBiz architecture by moving
core
applications out of the main OFBiz framework — similar to how plugins
are
currently managed.
This change would enable developers to build *custom ERP solutions*
without
being tied to all the default applications and their associated 750+
database tables. By decoupling applications from the framework, we can
provide a lighter and more modular foundation for building
domain-specific
or microservice-based solutions.
I strongly believe this approach will *significantly increase OFBiz
adoption* and flexibility, allowing users to leverage the framework
purely
as an enterprise-grade development platform rather than being
constrained
by bundled modules.
Thanks & Regards
--
Deepak Dixit
