Hi All, I’ve created the initial subtasks under OFBIZ-13305. I’ll continue adding more subtasks as I identify additional relevant work items during the analysis and implementation.
Kind Regards, Deepak Dixit On Tue, Apr 28, 2026 at 10:28 AM Devanshu Vyas <[email protected]> wrote: > > +1 for the proposal. > > I would also like to extend my assistance to Deepak in any way he requires > for development, testing, documentation, etc. > > > Thanks & Regards, > Devanshu Vyas. > > > On Mon, Mar 16, 2026 at 8:04 PM Moenieb Davids <[email protected]> > wrote: > > > +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 > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
