fineract-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [fineract] vidakovic opened a new pull request #1402: FINERACT-1189: fineract client as a separate module
Date Wed, 14 Oct 2020 10:58:11 GMT

vidakovic opened a new pull request #1402:

   ## Description
   Some pointers for your reviews:
   1. fineract-client uses the official OpenAPI Gradle plugin to generate sources; I've removed
the plugin that was previously used from fineract-provider; the CLI based code generation
is also removed (including spawning a separate Gradle build); just to say fineract-client
is a true module now
   2. the "allprojects" section contains now more plugin configurations that can be applied
to all modules; I've moved Spring dependency management, Rat and License check there, because
like this we only have to configure them once
   3. there is a new section (after "allprojects") that contain every plugin configuration
common to Java modules. Source sets, compiler arguments, JDK compatibility as well as Spotless
Java related configurations are done in one place here. We can move more stuff here, e. g.
Errorprone, Jacoco, Git properties, Checkstyle, Modernizer, Spotbugs, project report; these
plugins are not fineract-provider specific, but can be applied to any Java module (fineract-client
included); I just wanted to limit this first set of changes (already 25+ files changed)
   4. please look at line 26 of the build.gradle file in the root folder to see how the selection
of Java projects works; this allows us to use one common configuration for Java projects (see
line 333)
   5. fineract-client/src/main/templates contains OpenAPI/Swagger code generator template
files that fix a couple of style errors or just add licenses; just to have the bare minimum
there; these sources are still excluded from Spotless and other checks, because... well, generated
   6. in the current upstream develop branch the Swagger generated code is built on Travis
with "mvn test"; I would be surprised if we have any tests there... I remember there's a flag
to generate test stubs, but how useful are these skeleton tests then? Have to check this again
   7. I still have to decide how to handle the Swagger file ("fineract.yaml"). In my first
prototype I've copied it from fineract-provider to fineract-client, because I couldn't convince
Gradle to build the modules in a certain order (fineract-provider -> fineract-client);
it's not really a good practice to do this anyway in Gradle, but still there are a few mechanics
that should help (like declaring a project dependency or something along those lines). If
I manage to get this working then we don't need to Git manage fineract.yaml under fineract-client
(we can just pick it up in fineract-provider/build). Just FYI
   ## Checklist
   Please make sure these boxes are checked before submitting your pull request - thanks!
   - [x] Write the commit message as per
   - [x] Acknowledge that we will not review PRs that are not passing the build _("green")_
- it is your responsibility to get a proposed PR to pass the build, not primarily the project's
   - [x] Create/update unit or integration tests for verifying the changes made.
   - [x] Follow coding conventions at
   - [x] Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/api-docs/apiLive.htm
with details of any API changes
   - [x] Submission is not a "code dump".  (Large changes can be made "in repository" via
a branch.  Ask on the developer mailing list for guidance, if required.)

This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:

View raw message