this is great, accelerates on-boarding imo On Wed, Nov 4, 2026, 7:58 PM Ádám Sághy <[email protected]> wrote:
> Hi all, > > We have opened a large batch of well-scoped tickets aimed at new and > returning contributors. (Thank you Aleks!). > > Each one is small enough for a single pull request and describes where to > look and when it is done. > They are all labelled "beginner" and "beginner-friendly", so you can find > them with: > > > https://issues.apache.org/jira/issues/?jql=project%3DFINERACT%20AND%20labels%3Dbeginner-friendly%20AND%20statusCategory%3D%22To%20Do%22 > > The stories were built from a clean build of develop and a review of the > codebase. The warning counts, module and file lists in each sub-task come > straight from the build output. > > > 1. Fix compiler, Error Prone and Gradle warnings in the build > https://issues.apache.org/jira/browse/FINERACT-3092 (15 sub-tasks) > > A clean build prints about 2,280 unique warnings. They hide new > problems, and most of them are mechanical to fix. One sub-task per > warning category: EffectivelyPrivate, arrow switches, BooleanLiteral, > Javadoc, deprecated APIs, unchecked casts, Locale in toLowerCase, > pattern-matching instanceof, the generated Feign client templates > and Gradle 10 deprecations. > > > 2. Re-enable the Error Prone checks disabled in build.gradle > https://issues.apache.org/jira/browse/FINERACT-3108 (8 sub-tasks) > > build.gradle disables several checks with a "TODO fix remaining > usages" note (UnusedVariable, EmptyBlockTag, MissingSummary, > DirectInvocationOnMock, ReturnValueIgnored, ...). Fix the usages, > then switch the check back on so the problem can't come back. One > sub-task covers a crash in Error Prone 2.49 that the UnusedVariable > check hits on two of our classes. > > > 3. Move shared code out of fineract-provider so feature modules can be > split > https://issues.apache.org/jira/browse/FINERACT-3117 (6 sub-tasks) > > Loan and savings code can't leave fineract-provider while it depends > on notes, calendars, holidays, working days, account transfers and > interest rate charts that live only there. These sub-tasks move them > to fineract-core, or put interfaces in core. > > > 4. Move loan code out of fineract-provider > https://issues.apache.org/jira/browse/FINERACT-3124 (13 sub-tasks) > > 208 loan classes are still in fineract-provider. About 160 of them > don't depend on anything else in provider, so they can move first: > product mix, COB steps, jobs, external event serializers, batch > strategies, read and write services, API resources. Targets are > fineract-loan, fineract-progressive-loan and fineract-cob. > > > 5. Move savings, deposit and charge code out of fineract-provider and > fineract-core > https://issues.apache.org/jira/browse/FINERACT-3138 (8 sub-tasks) > > 170 savings and deposit classes are still in fineract-provider, > including 86 command handlers, plus savings and charge classes in > fineract-core. Targets are fineract-savings and fineract-charge. > > > 6. Split large service classes by functionality > https://issues.apache.org/jira/browse/FINERACT-3147 (15 sub-tasks) > > Fifteen sub-tasks across 13 services of 1,000 to 3,700 lines. > LoanWritePlatformServiceJpaRepositoryImpl (3,735 lines, 44 public > methods) is split into 3 sub-tasks: disbursement, repayments and > adjustments, and closing/write-off/transfer. Each sub-task suggests > how to split the class. The rule is extract, don't rewrite: no > behaviour change. > > > 7. Move business logic out of JPA entities > https://issues.apache.org/jira/browse/FINERACT-3163 (11 sub-tasks) > > 66 of our 253 entities take a JsonCommand, 23 run request validation > themselves, and SavingsAccount (3,840 lines) and Loan (1,884 lines) > contain calculations. Entities should only hold state and the > methods that change it. Parsing, validation and calculations move to > services, validators and calculators. > > > 8. Return typed objects from API resources instead of serialized Strings > https://issues.apache.org/jira/browse/FINERACT-3175 (14 sub-tasks) > > 449 methods in 75 *ApiResource classes build their JSON by hand and > return a String. They should return the response DTO and let > JAX-RS/Jackson serialize it, as the fineract-accounting resources > already do. The JSON clients receive, the OpenAPI spec and the > generated client method names must not change. > > > 9. Type-safe native SQL queries (QueryDSL) > https://issues.apache.org/jira/browse/FINERACT-2022 (51 sub-tasks so > far) > > Fineract builds about 500 native SQL queries as strings, so a > renamed or dropped column only fails at runtime. FINERACT-2022 (see > also FSIP-6) replaces them with QueryDSL SQL queries, whose query > classes are generated from the schema. A broken column reference > then fails the build instead of production. > > - The first 50 sub-tasks (SQL 001 to SQL 050) each cover one query. > They start with the accounting module, which is the pilot, and > continue into locking, currencies, tenants, external events, > arrears ageing and loan reschedule. > - Each sub-task names the class and line, for example > "[SQL 001] Retrieve all GL closures > (GLClosureReadPlatformServiceImpl:78)". > - The QueryDSL infrastructure (dependencies, Q-type generation, a > short developer guide) is not on develop yet. Please follow > FINERACT-2022 and wait for it to land before you pick up an SQL > sub-task. > - More sub-tasks will be added as the migration moves on module by > module. > > > *How to get started* > > - Pick a sub-task and comment on it to say you are working on it. > - Please don't pick up more than 3 at the same time > - One sub-task per pull request. Start the PR title with the ticket > key, e.g. "FINERACT-3093: Fix EffectivelyPrivate warnings in > DepositAccountReadPlatformServiceImpl". > - Behaviour must not change. Run ./gradlew build -x test before you > push, and the tests that cover your change. CONTRIBUTING.md and the > skills under .agents/skills explain how to test. > - Some tickets depend on others (the modularisation ones on the shared > code story, for example). The ticket says so where it matters. > - Questions are welcome here on the list or on the ticket. > > These are good first contributions. Each one makes the codebase safer and > easier to work on for everyone who comes after you. > > Thanks, > Adam S >
