[jira] [Assigned] (FINERACT-1177) Alt. distro? Spring Boot JAR is not great for "dropping in" Plugins
[ https://issues.apache.org/jira/browse/FINERACT-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandar Vidakovic reassigned FINERACT-1177: -- Assignee: Aleksandar Vidakovic (was: Michael Vorburger) > Alt. distro? Spring Boot JAR is not great for "dropping in" Plugins > --- > > Key: FINERACT-1177 > URL: https://issues.apache.org/jira/browse/FINERACT-1177 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Assignee: Aleksandar Vidakovic >Priority: Major > Fix For: 1.5.0 > > > 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. > [~ptuomola] [~aleks] do you perhaps have any thoughts about this? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (FINERACT-1177) Alt. distro? Spring Boot JAR is not great for "dropping in" Plugins
[ https://issues.apache.org/jira/browse/FINERACT-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Vorburger reassigned FINERACT-1177: --- Assignee: Michael Vorburger > Alt. distro? Spring Boot JAR is not great for "dropping in" Plugins > --- > > Key: FINERACT-1177 > URL: https://issues.apache.org/jira/browse/FINERACT-1177 > Project: Apache Fineract > Issue Type: New Feature >Reporter: Michael Vorburger >Assignee: Michael Vorburger >Priority: Major > > 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. > [~ptuomola] [~aleks] do you perhaps have any thoughts about this? -- This message was sent by Atlassian Jira (v8.3.4#803005)