Uploaded image for project: 'Apache Fineract'
  1. Apache Fineract
  2. FINERACT-1177

Alt. distro? Spring Boot JAR is not great for "dropping in" Plugins



    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.5.0
    • Component/s: None
    • Labels:


      While I was working on FINERACT-1127, I've realized that the Spring Boot JAR distribution is not great for us to open up Fineract to allow adding plugins to it...

      I've "solved" this in https://github.com/vorburger/fineract-pentaho/blob/develop/run by "unpacking" our 'official' JAR distro, and then dropping the plugin into that.

      The reason why we have to do like that is because https://github.com/vorburger/fineract-pentaho/compare/broken_no-unpack_Fineract-SpringBoot-JAR cannot work - that leads to NoClassDefFoundError ... Caused by: java.lang.ClassNotFoundException: when Java's (not Spring Boot's...) classloader was loading PentahoReportingProcessServiceImpl, it could not find ReportingProcessService - because that is hidden inside /BOOT-INF/classes/ where Spring Boot's special classloader will grab it from - but Java's can't find it.

      But it made me wonder... why are we distributing Fineract (only) as a Spring Boot magic JAR Why is Spring Boot not creating a "simple" good ol' uberJAR? Could / should we change that?

      Reading https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html, I don't immediately see an option to change that. Do you? https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#packaging-executable-configuring-unpacking or https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#packaging-layered-jars look like it's adding more magic, instead of less... Would perhaps https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/html/#reacting-to-other-plugins-application be more suitable for us, if we want to "open up" Fineract to let people easily add plugins to it? Or should we have https://docs.gradle.org/current/userguide/application_plugin.html based ZIP as an ADDITIONAL 3rd distribution (besides the JAR and WAR, which we could keep), instead of replacing the regular Spring Boot JAR?

      Or is this a total non-issue, we can simply document how future plugins can be installed, like my run script does? Could cause confusion.

      Petri Tuomola Aleksandar Vidakovic do you perhaps have any thoughts about this?


          Issue Links



              • Assignee:
                aleks Aleksandar Vidakovic
                vorburger Michael Vorburger
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: