[
https://issues.apache.org/jira/browse/FINERACT-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17211790#comment-17211790
]
Aleksandar Vidakovic commented on FINERACT-1189:
------------------------------------------------
[~Grandolf49] I can see the argument for doing this in a separate repository to
be able to adjust independently from the main project. These adjustments though
would be mainly around the mustache templates and there's only so much you can
do with them. So, at a certain point I think the templates will just generate
what we want and after that I don't see too many changes happening there.
Concerning availability of the client JARs of previous versions: well, the
driving artifact is the Swagger file which is tied to the main project
(fineract-provider); everything else is derivative; I don't see any added value
of a separate Git repo over having this as a module (have some more comments
below)... but maybe I am missing here something? I agree with the argument that
waiting for fixes could be an issue, but that argument is true for the client
lib as it is for Fineract itself. I think at the moment there are no plans for
patch releases of Fineract itself, but it is not totally impossible to do that
(just our resources might be a bit thin for that right now).
I'm not sure if I understood correctly if the intention is to generate the
client project and then check that generated code into Git? If I understood
this wrong the please ignore the following paragraph. But if that is the case
then I'm not sure how useful that would be (or if that is the intended usage).
I think the intention of that code generator is to get people going quickly, so
they generate everything one needs to build an API client based on a Swagger
file. But as you can see from the templates the authors didn't pay too much
attention to code formatting (see curly on same line and separate line; to a
certain extent this can be taken care of by Spotless, but not everything) and
the project related mechanics (Gradle or Maven) are also just bare minimum to
make this work (in the case of Gradle the templates generate something really
old... I want to say version 2.x, but maybe it's a little bit newer). That code
is intended just to pass the compiler and not to be edited manually. In anyway,
if we would just use the Swagger/OpenAPI file as the only artifact managed in
Git then things become actually quite easy. BTW: I would also suggest using the
official OpenAPI Gradle plugin to do that, because then the generated sources
are created in the build folder and IDEs automatically detect those additional
source folders; and: no Bash scripting is needed for that approach (which has a
tendency to break on Windows). That project or module would be then very
minimalistic (in terms of managed artifacts) which is nice for maintenance (the
only thing we need to take care of is the Swagger file). The only other sources
I'd add to the client (later): Spring Boot auto-configuration; that would be a
neat convenience for users, but at this point it's non-essential and can wait.
In terms of publishing to Maven Central: I see no problem neither with a
separate Git repo nor if we add the client as a module. Personally I'm a
proponent of mono repos; refactoring is just so much easier.
I have though some caveats with a separate Git repository: how do we intend to
keep the Swagger file up to date in the client repo? This turned out to be
already a bit of a challenge in my current effort to create a multi-module
build in FINERACT-1171 and would be harder with separate Git repos. Also:
should the client JAR be part of the Fineract release? How would we orchestrate
that? And last: if we manage Fineract and the client lib in separate repos then
we have to do some build orchestration (see your notes about Travis)... which
is certainly possible, but I'd argue with client being a module the pieces are
just falling automatically in place without any further effort (and
maintenance).
> fineract-client as separate module
> ----------------------------------
>
> Key: FINERACT-1189
> URL: https://issues.apache.org/jira/browse/FINERACT-1189
> Project: Apache Fineract
> Issue Type: Sub-task
> Reporter: Michael Vorburger
> Assignee: Aleksandar Vidakovic
> Priority: Major
>
> Would it be possible to extract JUST the work related to making
> fineract-client as separate module from
> [https://github.com/apache/fineract/compare/develop...vidakovic:feature/FINERACT-1171]?
> In terms of logical sequencing, perhaps this would be simplest to do after
> FINERACT-1188, with fineract-client as the 1st of more to come modules, but
> not yet including fineract-api and fineract-doc?
> I imagine that this would help with later making FINERACT-1102 possible?
> If it's possible, it's perhaps easier if you do not yet include any
> improvements to fineract-client - JUST the build changes, and then raise a
> separate PR after for changes such as adding
> src/main/templates/java/retrofit2/CollectionFormats.mustache and all those
> things? Create a separate JIRA, as a subtask here or standalone Improvement,
> about whatever all those changes are required for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
