The change is not breaking any functionality. The reason for bringing this here is mainly due to the files involved: over 220 files moved from either fineract-core or fineract-provider to the new fineract-party module
This is the only important aspect of the change, as I mentioned in the original email, we can validate the file movement with a git command. Thanks and regards Alberto On Tue, Jul 7, 2026 at 9:48 AM James Dailey <[email protected]> wrote: > But this is a breaking change, right? The idea of Modularization was > discussed for sure, but this goes well beyond that because it will not > allow for backward compatibility. And, yes! thanks for bringing it to the > list. As you noted, it also potentially breaks the rule regarding a > "single massive code" change. > > James Dailey > > > > On Mon, Jul 6, 2026 at 9:55 AM Jose Alberto Hernandez < > [email protected]> wrote: > >> @James This isn't the first time we've discussed Fineract modularization, >> but due to the quantity of files involved in this particular case, we are >> informing you here to get some feedback. >> >> Fineract provider remains current; however, we are creating Gradle >> modules to separate different domain modules, ie. loan, savings, taxes, >> branch and now we would like to have party (for Clients, Groups, Centers, >> etc) >> >> Fineract provider has a dependency on all of them. >> >> Thanks and regards >> Alberto >> >> >> >> On Mon, Jul 6, 2026 at 9:55 AM James Dailey <[email protected]> >> wrote: >> >>> Is this the first we’ve heard of this? >>> >>> Fineract provider is a key component that many others assume will remain >>> available “as is”. Whats the migration path? Backwards compatible? >>> >>> >>> >>> Sent from Gmail Mobile >>> >>> On Mon, Jul 6, 2026 at 6:36 AM Jose Alberto Hernandez < >>> [email protected]> wrote: >>> >>>> Hi all, >>>> >>>> As part of the ongoing modularization effort (FINERACT-1932), I'd like >>>> to share a change that introduces a new fineract-party Gradle module, >>>> extracting the Client, Group and Address domains >>>> (org.apache.fineract.portfolio.client, .group, .address) out of >>>> fineract-provider and fineract-core into their own module. >>>> >>>> The diff touches *229 files*, which may look large at first glance, >>>> but the breakdown shows it is almost entirely mechanical: >>>> >>>> - *209 files are pure moves* (100% rename similarity, zero content >>>> changes): *183 from fineract-provider and 26 from fineract-core* — 126 >>>> client, 67 group and 16 address classes. Package names are unchanged, so >>>> there is no impact on the REST API, database schema, or existing imports. >>>> - *9 new files*: the module's build.gradle and dependencies.gradle, >>>> plus *7 AsciiDoc chapters documenting the party domain* under >>>> fineract-doc (overview, data model, use cases, flows, business rules, API). >>>> - *11 one-line Gradle edits*: registering the module in >>>> settings.gradle and adding implementation(project(':fineract-party')) to >>>> the modules that consume it (provider, loan, savings, branch, etc.). >>>> >>>> Total: 900 insertions, no deletions or logic changes. You can verify >>>> the move-only nature with git diff -M --summary, and file history is >>>> preserved via git log --follow. >>>> >>>> Feedback is welcome — in particular on the module boundaries (what >>>> should ultimately live in party vs. core) and on whether to split this kind >>>> of extraction into smaller commits in the future. >>>> >>>> Thanks, >>>> Alberto >>>> >>>
