Hi Michael, Thanks for your input.
> > 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: > I agree — and that’s part of the plan. Once the community agrees on the base idea, I’ll prepare a detailed plan on the JIRA ticket. If needed, I can also create a Confluence page with more in-depth details and migration steps. > * Where is the dividing line between framework and applications? > In the current structure, application components are designed to provide base OOTB implementations for ERP applications; the rest belong to the framework. In the initial phase, we’ll need to move some dependent code from the framework to the application modules — for example, the EntityPermissionChecker class, which depends heavily on the Content data model. We should remove that class and related logic, and replace it with a dedicated permission service. > > * 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)? > >From my initial POC, all data models required to run the framework are already part of the framework. (If we find any, we will move them to the framework.) We only need to update the code where the framework depends on userLogin.partyId. For example: - Update theme header files to display names from UserLogin instead of Party. - Update CsrfUtil to use userLoginId instead of partyId for CSRF token caching. > > * 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) > We might need to consider restructuring in the future, but that should be handled as a separate step. For now, detaching applications from the framework is the main focus. I recall Jacques mentioned that GitHub supports cloning individual folders — this could help users fetch only the required applications for customization. > > * Can we create a technical option that allows users of OFBiz > applications to configure the framework in order to remain updatable? > Since the framework itself is a utility layer, any custom implementation can still be deployed on newer releases. To make upgrades easier, we should start publishing *release notes with major or breaking changes*, along with *upgrade instructions*. Framework changes should always maintain backward compatibility through deprecation and migration guidelines. We can also version and release the applications, similar to the plugins. > > * How are Util* classes organized (centrally vs. application-specific > vs. ...)? > > * etc. > We’ll need to review the Util* classes — any that are application-specific should remain in applications, while those with general-purpose functionality should be part of the framework. I’ll add a detailed plan to the JIRA ticket based on my findings. >From my initial work, I was able to run the framework successfully after making minor adjustments (as mentioned above). I’ll also create subtasks for each specific change item. Thanks & Regards -- Deepak Dixit ofbiz.apache.org > > 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 > >>>> >
