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

Reply via email to