+1
... as for components some more info:
- Adam is right, fineract-client is a self standing module, no
dependencies to any other build module in the repository
- same is true for fineract-command
- effort on the way to refactor/migrate all packages/features to the
"new" command processing... advantages:
- full type safety in REST controllers, no more manual JSON
de-/serialization
- add new commands/handlers without effort aka no centralized switch
statement
- Jakarta validation right where we receive REST requests aka in the
controllers
- no more JSON related code in business logic services
- centralized authorization enforcement rules where they belong
(read: in the http security Java configuration); gets us closer to
modular/configurable security
- ... and more cleanups... 4 modules are already migrated, 16 more
are planned (roughly half of the packages/features of Fineract)
- Note: we start with the less important packages first (not loan)
When the new command processing is in place it will be a lot easier to
create proper modules... or at least aim for a modular monolith. The
problem is that in general we have a lot of interdependencies between
packages/modules/features (read: no proper domain boundaries). Having said
that... there is another idea being currently discussed to detangle those
dependencies by removing direct dependencies/service function calls with an
internal event based architecture. No code has landed yet, still in the
sketching phase.
FYI
On Tue, Dec 16, 2025 at 10:23 PM Paul <[email protected]> wrote:
> 👍
>
> On Tue, Dec 16, 2025 at 1:28 PM James Dailey <[email protected]>
> wrote:
>
>> +1
>>
>> Kick it off
>>
>> On Tue, Dec 16, 2025 at 9:47 AM Adam Monsen <[email protected]> wrote:
>>
>>> Hey y'all, let's talk about the 1.14.0 release!
>>>
>>> I volunteer to be release manager.
>>>
>>> Our last release was completed on Oct 20
>>> <https://lists.apache.org/thread/f1ymthf5mt81tzyjbmn11yth956c02n1>, so
>>> if we stick with quarterly releases we should do the Q4 release now-ish.
>>>
>>> I'm looking at dee325ec
>>> <https://github.com/apache/fineract/commit/dee325ec7f26e559c839e59bd5efdafda2d24801>
>>> as a likely branch point since CI is green for that commit. I brought
>>> it up in chat
>>> <https://mifos.slack.com/archives/C028634A61L/p1765902189794649> and
>>> haven't heard any dealbreakers yet. Please speak up asap here or in chat if
>>> there's any reason to delay the release. Stability is key
>>> <https://lists.apache.org/thread/sq9x7qg04s3fj5ycqrs7z3sqxm7tp434>.
>>>
>>> I'll follow process in the existing docs
>>> <https://fineract.apache.org/docs/current/#_releases> (updating as I
>>> go, as usual) and use the Fineract Release Plugin, and I'm also going to
>>> pilot the ATR (Apache Trusted Releases) platform
>>> <https://tooling.apache.org/trusted-releases.html> we've been discussing
>>> lately
>>> <https://lists.apache.org/thread/f99mhvxg9l3wz17thmwonvgn6vyz05vq>.
>>> I've been learning about ATR, trying it out, and chatting with the
>>> maintainers. I'm excited it will make our release process both simpler,
>>> more efficient, and more robust.
>>>
>>> I'll start today and hopefully we can finish the ceremony before my
>>> holidays kick off, but it's also OK if it needs to bleed over into the new
>>> year.
>>> On 10/17/25 08:59, Adam Monsen wrote:
>>>
>>> Thank you Terence! Everything helps. I'll take you up on that offer of
>>> assistance and I appreciate it greatly. I'll look for places we can team up.
>>>
>>> re: components ... I think it was Aleks who coached me into thinking of
>>> the codebase as a monolith, even with the optimistic separation of the code
>>> into modules. The logic is not evenly distributed, it's mostly useful as
>>> one big chunk (with the exception of fineract-client, perhaps?). At any
>>> rate, the modules roll up into a single gradle project with multiple gradle
>>> sub-projects and building everything is not really any harder than building
>>> an individual module. As far as module maintenance goes: I don't know, I've
>>> done very little of that lately. But in an IDE we're basically just working
>>> on the whole monolith at once, right?
>>>
>>> In terms of improving/simplifying the code as a way to improve
>>> everything (including releases), the fundamental action that would probably
>>> be the most helpful and also the hardest is culling cruft we don't need or
>>> use (starting with defining "we" and "need").
>>>
>>>
>
> --
> --
> Paul
>
