You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Jose Alberto Hernandez <jo...@gmail.com> on 2026/07/06 13:35:56 UTC
[DISCUSS] FINERACT-1932 — New fineract-party module (Client/Group/Address extraction)
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
Re: [DISCUSS] FINERACT-1932 — New fineract-party module (Client/Group/Address extraction)
Posted by Jose Alberto Hernandez <jo...@gmail.com>.
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 <ja...@gmail.com> 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 <
> josealbertohm@gmail.com> 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 <ja...@gmail.com>
>> 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 <
>>> josealbertohm@gmail.com> 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
>>>>
>>>
Re: [DISCUSS] FINERACT-1932 — New fineract-party module (Client/Group/Address extraction)
Posted by James Dailey <ja...@gmail.com>.
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 <
josealbertohm@gmail.com> 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 <ja...@gmail.com>
> 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 <
>> josealbertohm@gmail.com> 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
>>>
>>
Re: [DISCUSS] FINERACT-1932 — New fineract-party module (Client/Group/Address extraction)
Posted by Jose Alberto Hernandez <jo...@gmail.com>.
@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 <ja...@gmail.com> 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 <
> josealbertohm@gmail.com> 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
>>
>
Re: [DISCUSS] FINERACT-1932 — New fineract-party module (Client/Group/Address extraction)
Posted by James Dailey <ja...@gmail.com>.
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 <
josealbertohm@gmail.com> 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
>