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 >
