Hi,
We had a short private discussion with Omar.
He explained me that I did not get right what he meant with the compete word. It was
about " Spring and ( Jakarta+ )"
This message is to clarified what I wrongly interpreted (mostly because I'm
French) and what Omar clearly explained.
By "Jakarta+" I guess Omar meant "Jakarta EE <https://fr.wikipedia.org/wiki/Jakarta_EE>" which is indeed not related with our replacement of
javax.servlet.* by jakarta.servlet.*
For Spring I guess most people got it right, sorry for the confusion. Not a big
deal anyway.
Jacques
Le 23/10/2025 à 16:38, Jacques Le Roux a écrit :
Thanks for feedback Omar,
Actually web tools is indeed an application, but part of framework, no worries.
The framework team should not have any issues with Spring since it's not used
in OFBiz OOTB.
That could indeed be an issue for OFBiz users... among others... ;)
We moved to Jakarta few months ago, so it should no an issue either.
HTH
Jacques
Le 23/10/2025 à 14:59, Omar Abdullwahhab a écrit :
Hi all,
I know this will be easy task for you, and I already did this and
successfully run the framework with only ( web tools application ).
And I would like to encourage you to do this as It will make framework
developers focus more on the technology, and the business application
developers in business and little bit in technology.
And the framework team will compete with Spring and ( Jakarta+ ).
And business applications with other ERPs.
Omar Abu-Arab
Java Engineer
On Thu, Oct 23, 2025, 3:39 PM Jacques Le Roux<[email protected]>
wrote:
Hi Deepak,
Thanks, I sometimes wondered indeed why we keep the applications in what
we call the framework. After almost 25 years, I think it could be good
decision to separate applications from the framework. Even if of course it
will be more work for contributors and committers. Because, unlike for the
plugins, often changes in one of them imply change in the other, not
always.
My 1s thought
Jacques
Le 23/10/2025 à 14:02, Deepak Dixit a écrit :
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
