[
https://issues.apache.org/jira/browse/FINERACT-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17194761#comment-17194761
]
Michael Vorburger commented on FINERACT-1127:
---------------------------------------------
[~ptuomola] Yes. Agreed. That would actually be pretty cool, IMHO. It's not
quite what I originally had in mind and described above, but as a a first step,
I love it. And I do think this could add a lot of real practical of value to
this project... because this would, IMHO, be, much, better than that "forked"
solution that is currently being promoted, if you've followed various related
confusing posts on list. That solution will keep requiring someone to rebase
and release a separate project that is de-facto a Fineract fork. This approach
would avoid that.
But there are some minor practical technical details we would have to figure
out together here, no? For one, there currently is no easy way to have an
entirely separate project, imagine say e.g. a
[https://github.com/ptuomola/fineract-reporting-pentaho-plugin], be "built
against" what
{{[PentahoReportingProcessServiceImpl|https://github.com/apache/fineract/pull/1262/files#diff-0708dfc4fbb4b67f43b9b935c8bb1ad8]}}
imports, do you see what I mean? We can't use
{{build/libs/fineract-provider.jar/.war}} (I trust you'll understand and agree
with why). The most pragmatic and simple initial quick solution may be for such
a {{fineract-reporting-pentaho-plugin}} project to use just
{{../fineract/build/classes/java/main/}}?! According to
[https://docs.gradle.org/current/userguide/declaring_dependencies.html], that
may be possible using something like \{{dependencies { implementation
files("../...") }}} ? It's a bit of a hack, of course, and somewhat brittle,
but perhaps good enough to get this off the ground? Later in the future perhaps
a "stable plugin API", published as an "official artifact", could be better.
If you want to have a go at this some time, by all means please do! Otherwise I
may be motivated to try to do this on some rainy autumn weekend in the coming
weeks (or months) - I'll add this fairly high up on my personal Fineract
TODO... but I would love for you to get to it, first!
> Modularize Fineract to allow something like e.g. the Pentaho integration to
> be built and run separately
> -------------------------------------------------------------------------------------------------------
>
> Key: FINERACT-1127
> URL: https://issues.apache.org/jira/browse/FINERACT-1127
> Project: Apache Fineract
> Issue Type: New Feature
> Reporter: Michael Vorburger
> Priority: Major
>
> [~francisguchie] thanks for raising
> [https://github.com/apache/fineract/pull/1262/files] for FINERACT-1094, even
> though we cannot merge it due to licensing, it helps at least me to see it
> nicely isolated like that, e.g. for this discussion!
> Seeing that, and subsequent FINERACT-1125, led me to wonder if an alternative
> future architecture approach here could be to have a 3rd-party, such as the
> Mifos Initiative, offer Pentaho integration for Fineract not anymore by
> forking Fineract and adding code to it (which is always a PITA to maintain,
> in the long run), but by building and releasing an entirely separate runnable
> binary artifact (WAR / JAR) for it... this could be very neat even from a
> runtime perspective - completely separate REST API, and (possibly "heavy"?)
> report generation?
> _One could even image breaking out running scheduler jobs separately from API
> serving. Ultimately, this could effectively be the start of breaking Fineract
> 1.x into a CN-like "microservices" deployment... but I'd envision that to,
> always, just be one option, a possible alternative - with the current WAR/JAR
> remaining as is, forever - but it would just "assemble modules" for the
> "monolithic deployment distribution". Anything along these ideas is further
> down the line, but starting with making this possible for reporting could be
> a pragmatic start.... let's focus on that only, in this issue._
> This is more of a still somewhat vague idea at this stage. The next step
> would consist of spending more time understanding the details of how
> Fineract's {{ReportingProcessService}} is designed... I personally don't know
> that much about it, but looking at PR #1162, one can kind of gather that this
> {{PentahoReportingProcessServiceImpl}} needs to implement
> {{ReportingProcessService}}? What would it take for the front-end to be able
> to call another service (or Fineract to HTTP redirect reports to an external
> service...), and then for such an external service to be able to... do
> exactly what, actually - what's the lowest common denominator integration
> touch point, here? From an only very quick glance at the code, it looks like
> we're basically "passing through" JDBC connection details? So... what one
> would need is to be able to build an external Fineract (non-CN) service that
> can access the same DB? Sharing a minimal amount of
> {{fineract.infrastructure.core}} code, as a library...
> [~francisguchie], [~ptuomola], [~awasum], [~xurror], [~edcable] FYI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
