+1 Proposal of moving applications out of the OFBiz framework looks good. It will make things simpler for both framework and app developers.
Kind Regards, Chandan Khandelwal On Thu, Mar 12, 2026 at 10:24 AM Arun Patidar <[email protected]> wrote: > 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 > > > > >>>>>> > > > > > > > > > >
