+1. I would perhaps add my name to assist with tasks as scoped. Perhaps initially, I can provide a resource to do some performance testing as well as assisting with dev, dependant on sizing and scope of work
Regards [email protected] On Mon, 16 Mar 2026, 15:32 Taher Alkhateeb via dev, <[email protected]> wrote: > > +1 > I also suggest more layers, including a separate domain + service (the > most valuable part) to be its own repo. The architecture would be something > like: > Custom Component → Applications → unified service + model → framework > Custom Component → unified service + model → framework > or in the future: > Custom Component → unified reusable screens → unified service + model → > framework. > This gives flexiblity, and allows some serious refactoring to start to > happen to the various sub-systems that badly need it. > Taher > > > On Monday, March 16, 2026 13:44 +04, Ratnesh Upadhyay < > [email protected]> wrote: > > > +1 for this proposal. > > Decoupling applications from the core framework and adopting a more > plugin-oriented architecture is a great step toward modernizing OFBiz. Also > I agree that It would make the framework lighter and better suited for > building custom ERP or domain-specific solutions, and would definitely > increase the adoption of OFBiz with greater flexibility. > > Best Regards, > Ratnesh Upadhyay > > *HotWax Systems* > *Enterprise open source experts* > > http://www.hotwaxsystems.com > > On Mon, Mar 16, 2026 at 10:50 AM Chandan Khandelwal < > [email protected]> wrote: > > > +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 > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > >
