Hi Deepak, +1 on the proposal. I believe the idea to separate the applications component from the OFBiz framework is very promising and aligns well with current industry demands.
Best regards, --- Arun Patidar On Wed, Mar 11, 2026 at 10:47 AM Divesh Dutta < [email protected]> wrote: > Hi Devs, > > Based on all the conversations, I think we can at least start by looking at > the plan. As Deepak suggested, he will either put notes on the Jira ticket > or create a Confluence document to share the plan. And then we can discuss > his proposals and reach a conclusion. > > Since Deepak plans to make minimal changes to the existing codebase to > separate the framework independently from the applications, I think it's a > good time to review and discuss the plan together. > > I vote that we start by discussing the plan. I would love to see Deepak's > plan. > > If others are interested, please vote for it. > > Thanks > -- > Divesh Dutta > > > > > > > On Mon, Nov 3, 2025 at 3:50 PM Jacopo Cappellato < > [email protected]> wrote: > > > Hi Michael, > > > > Thanks for your message and for sharing your thoughts. > > > > Just to clarify, I’m not directly involved in the separation work that > > Deepak is proposing, so I don’t know all the details of his current > > implementation efforts. My understanding, however, is that he will > > work closely with the community, as he has already started to do, and > that > > his progress and findings will continue to be discussed and refined > through > > the usual collaborative process. In that sense, the outcome will > naturally > > be shaped and controlled by the community. > > > > From what Deepak has shared publicly and from a few direct exchanges I’ve > > had with him, my impression is that his first and main goal is to make a > > minimal set of changes to the existing codebase to allow building and > using > > the framework independently from the applications. I believe this limited > > and practical objective is something we can rather easily agree on as a > > good first step. > > > > After that, of course, there may be different opinions about further > > work—for instance, which parts of the data model belong in the framework, > > or whether the framework should include any data model at all. I’d > suggest > > that we defer those broader discussions to later stages so we can stay > > focused on the specific and achievable changes needed to reach the > initial > > goal. > > > > Best regards, > > Jacopo > > > > On Sat, Nov 1, 2025 at 1:29 PM Michael Brohl <[email protected]> > > wrote: > > > > > Hi Jacopo, > > > > > > I might have missed to make my points clearly enough so I try to do so > > > inline. > > > > > > Thanks and regards, > > > > > > Michael Brohl > > > > > > ecomify GmbH - www.ecomify.de > > > > > > Am 30.10.25 um 09:06 schrieb Jacopo Cappellato: > > > > 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. > > > > > > I strongly belive that core questions should be adressed and answered > > > *before* we make such an impactful change to the codebase. We should > > > have a clear plan and common understanding on the outcome and the up- > > > and downsides. > > > > > > We should also have a clear plan on how to support the users who built > > > their projects on the actual setting. > > > > > > > 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. > > > > > > With organizing entity definitions in this context I meant: which > > > entities (and functionality) will be part of the framework and which > > > will not. > > > Where do we want to draw the line between framework and applications > > > concretely? > > > > > > Which code will be part of the framework in the future and which will > > not? > > > > > > > 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. > > > > > > I am not sure if I entirely understand this approach. > > > > > > I fully recognize that there may be work on the code that does not > > > result in any external changes, but internally results in cleaner, more > > > structured code. However, the time will come when the actual split is > to > > > take place, and then there should also be a concrete idea of what > impact > > > this will have and how we want to deal with it. > > > > > > > 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. > > > > > > I completely agree with that on this fundamantal level. > > > > > > > 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. > > > > > > I'm sure Deepak and you will be working on this responsibly but I also > > > have difficulties with the feeling to just start and see where it goes. > > > > > > Maybe we'll just need some examples to have a better understanding of > > > the plans your have in mind. That is why I raised the fundamental > > > questions, which certainly have not yet been fully and thoroughly > > > thought through. > > > > > > I definitely want to avoid undertaking extensive renovations without > > > having a clear picture of the consequences. > > > > > > > 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. > > > > > > How do you plan to move this forward in a way that we can follow the > > > work and have discussion / synch points when we come to fundamental > > > changes? > > > > > > > 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 > > > >>>>>> > > > > > >
