[
https://issues.apache.org/jira/browse/FINERACT-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17169293#comment-17169293
]
Michael Vorburger commented on FINERACT-838:
--------------------------------------------
With [pull/1206|https://github.com/apache/fineract/pull/1206] now merged
(thanks [~Grandolf49]!), and very minor follow-ups in
[pull/1224|https://github.com/apache/fineract/pull/1224] and
[pull/1226|https://github.com/apache/fineract/pull/1226], what's left here? I
can think of 2-3 things remaining, maybe others have further thoughts (Cc
[~Manthan] and [~ptuomola]):
A. It strikes me that currently this is never "built" in CI. If e.g.
[pull/1226|https://github.com/apache/fineract/pull/1226] was wrong, the PR
would not fail. It's, currently, essentially "just" an additional Gradle plugin
which may or may not work - and could easily break in future upgrades, noticed
only through manual code re-generation and future re-testing by someone. In an
ideal world, I would expect a "full build" to include running this {{./gradlew
generateSwaggerCode}} - objections, anyone? Shall we add it only on
[{{.travis.yml}}|https://github.com/apache/fineract/blob/develop/.travis.yml],
or make it a dependency in Gradle so it locally builds for everyone as well?
B. Even if we do A. it's still not really "tested" at all, of course. We don't
know if the generated code is a working client. Of course I "trust"
[~Grandolf49] and {{swagger-codegen}}, but... in an ideal world, we should have
some sort of {{fineract-client-demo}} (?) as a small separate project in the
git root directory (of Apache Fineract core, not separately/outside!) which
depends on the client artifact generated by {{./gradlew generateSwaggerCode}},
and invokes at least some of the generated APIs. This could be "interesting",
because I expect in a naive first implementation, Gradle may "choke" (cough) on
a dependency to a yet-to-be-generated artifact... but I'm sure there is some
smart way to do that right? Ideally, this IMHO should always be run, e.g. on
Travis CI. We would of course need a "back-end server" - the easiest would
probably be to run this against the local server we're anyway starting for
{{integrationTest}}, in a separate new Gradle task with the appropriate
dependencies?
C. If we want to "promote" the use of this, we should probably "distribute" it?
Think e.g. a possible upcoming 1.4.0 release - shall we include this new JAR as
part of that Fineract distribution ZIP we're going to upload? Push it to Maven
Central?? ;)
> Swagger generated client libraries
> ----------------------------------
>
> Key: FINERACT-838
> URL: https://issues.apache.org/jira/browse/FINERACT-838
> Project: Apache Fineract
> Issue Type: Sub-task
> Reporter: Michael Vorburger
> Assignee: Chinmay Kulkarni
> Priority: Major
> Fix For: 1.4.0
>
>
> In the review discussion of the first Swagger PR
> https://github.com/apache/fineract/pull/629 (which got superseded by
> https://github.com/apache/fineract/pull/695), this came up:
> {quote}The other plugin org.hidetake.swagger.generator is used to generate
> code from the openAPI spec file using swagger-codegen. So this does not
> generate response.json. It rather uses response.json to generate client
> code.{quote}
> and {quote} think i had explained the usage of this in my gist
> https://gist.github.com/kangbreder/034f47e2e8015cee10b48b7c5f1b8df1,
> generating client libraries and language-specific SDKs in languages such as
> java and angular from swagger specification file. This was part of the goals
> of the project listed in
> https://mifosforge.jira.com/wiki/spaces/RES/pages/812810251/Google+Summer+of+Code+2019+Ideas.{quote}
> Having (Swagger automatically generate!) client libraries in Java (and even
> other languages?!) seems like a cool idea. It's also something that perhaps
> needs a bit more investigation than only adding the respective Gradle plugin.
> If we actually do do this, after having done all of the work in the other
> Sub Tasks, then I think we would have to include sample code in the repo
> building against the generated client libraries to test and illustrate their
> usage. We would also have to publish those client libraries, e.g. as
> downloadable JAR from the release page (or later even made available on Maven
> central). It would perhaps be clearest if there was another directory in the
> Fineract source tree, next to and outside of not inside, the
> fineract-provider (which is the "server") for this purpose.
> [~kangbreder] [~awasum] [~sanyam] ([~sanyam96] ?) FYI
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
