Hello Deepak
I understand well your vision, and appreciate all effort that you done
on this way.
From my side (my translation of the discussion about the votes) we
voted to don't backport Jakarta on 24.09 to secure production site
because the next release have minor few comfortable improvement and one
major with jakarta.
After the second vote the next release is on November, effectively is
far and I'm fell like you I have some good improvement that I want to
share with user, like typesafe config that increase OFBiz capacity for
clustering, but freeze it to wait the releasing to not introduce any non
detected regression.
If I refocus on git repo separation, idea to do this before the next
release, with intention of benefiting to users, indicate (for my mind)
that we need to change our release process. Do we want publish just one
archive : ofbiz framework + application + plugins ? or two : ofbiz
framework, ofbiz framework + application + plugins
Otherwise, let's change our releases; in that case, we'll need to
prepare the build scripts so it doesn't turn into a nightmare for
whoever is setting them up. If we don't change anything or keep the
ofbiz framework + application + plugins archive, well, okay, the risk is
effectively zero :)
So to resume If we decide what to publish, this will determine when you
can realize the cut.
Cheers,
Nicolas
Le 13/07/2026 à 06:31, Deepak Dixit a écrit :
Hi Nicolas,
Thanks for your feedback.
My thinking behind targeting this for 26.11 is that the community and
users would be be able to benefit from the application separation much
sooner. If we postpone it until after the 26.11 release, users may
have to wait another release cycle—potentially one or two years—before
they can take advantage of it.
Also, this change is only a repository separation. The applications
will continue to work exactly as they do today. There are no
functional changes to the applications themselves, and I don't plan to
change the existing folder hierarchy. If needed, we can even provide a
Gradle task to automatically clone the applications repository during
setup, making the transition nearly transparent for users.
Since we're still about four months away from the 26.11 release, I
believe we have sufficient time to:
- Thoroughly test the changes.
- Prepare comprehensive migration and upgrade documentation.
- Address any issues identified by the community during testing.
If you're seeing any specific complications or risks with including
this in 26.11, could you please share them? I'd be happy to discuss
them and work through them before the release.
My goal is to make this transition as smooth as possible while
allowing users to benefit from a more modular framework without having
to wait for another release.
Best regards,
--
Deepak
https://ofbiz.apache.org
On Mon, Jul 6, 2026 at 1:54 PM Nicolas Malin via dev
<[email protected]> wrote:
Hello Deepak,
Thanks for all your efforts on this way, I suggest to realize the git
separation after the release 26.11 creation.
I imagine that you already had in mind anyway, but just want to
make sure :)
Nicolas
Le 01/07/2026 à 09:53, Deepak Dixit a écrit :
> Hi all,
>
> As a follow-up to the recent discussion on separating the
applications from
> the framework, I’d like to propose creating a new Git repository
named
> *ofbiz-applications*.
>
> Discussion thread:
> https://lists.apache.org/thread/8rvtlfyo3hqg1kgmmo9t9tybw5vjfqt9
>
> Over the past several weeks, we’ve completed the dependency
cleanup work
> tracked under *OFBIZ-13305*. The framework no longer has runtime
> dependencies on the applications, and the remaining references
have either
> been removed or migrated into the framework where appropriate.
>
> The goals of creating a separate repository are to:
>
> - Decouple the applications from the framework.
> - Allow the framework and applications to evolve independently.
> - Simplify the framework repository and make it easier to
use as a
> standalone foundation.
> - Make framework upgrades significantly easier for adopters.
>
> Today, one of the biggest challenges when upgrading OFBiz is merging
> changes in the application layer, where business logic often
conflicts with
> custom implementations.
>
> As a result, many adopters postpone framework upgrades, making
it more
> difficult to benefit from the latest framework improvements, bug
fixes,
> performance enhancements, and, most importantly, security fixes.
>
> By separating the applications from the framework, adopters will
be able to
> upgrade the framework independently while keeping their customized
> application code unchanged. This will significantly reduce merge
conflicts,
> simplify framework upgrades, and encourage users to stay current
with the
> latest framework releases, including *critical security* updates.
>
> If any additional dependencies are discovered after the split,
we can
> address them through follow-up JIRA issues without blocking the
repository
> separation.
>
> Unless there are any objections, I’d like to proceed with
creating the new
> *ofbiz-applications* Git repository and then begin migrating the
> application modules from the ofbiz-framework repository.
>
> Please share your feedback or concerns.
>
> Thanks
> --
> Deepak Dixit
> ofbiz.apache.org <http://ofbiz.apache.org>
>
