Hi, The application separation effort is now in good shape. All known application dependencies in the framework have been addressed, and all related subtasks under *OFBIZ-13305* have been completed.
If we discover any remaining dependencies during or after the separation, we can create follow-up JIRA issues and address them independently. At this point, I believe we’re ready to move the applications out of the ofbiz-framework repository into a new ofbiz-applications repository. I’ll start a new thread to discuss the creation of the new Git repository for ofbiz-applications and the migration plan. Thanks & Regards -- Deepak Dixit ofbiz.apache.org On Wed, Apr 29, 2026 at 1:15 PM Deepak Dixit <[email protected]> wrote: > 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 > > > > > > > > > >>>>>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
