Hi All, Apache Syncope had to write a plugin to integrate their solution with Spring 5. https://github.com/apache/syncope/commit/17a8eb5d99a84608a64927b00e7d9352d640517e
Looks like the Spring team will support just 2 ORMs officially moving forward: Hibernate and EclipseLink. Good thing Eclipse link happens to be compatible with Apache license and also officially supported by future version of Spring. On Wed, Jul 10, 2019 at 8:50 AM Michael Vorburger <m...@vorburger.ch> wrote: > On Wed, Jul 10, 2019 at 8:43 AM Isaac Kamga <u2is...@gmail.com> wrote: > >> Hello devs, >> >> Just thought I should remind the community about why these migrations are >> necessary. >> >> The rationale behind migrating the ORM from Hibernate is that Hibernate >> ORM's license[1] falls under the ASF's Category X[1]. >> >> Not complying to the ASF's licensing requirements is a sure-fire method >> to never getting an official release for Fineract CN. >> >> Does anyone think there's another way around these ? >> > > I doubt it. I think Hibernate is, unfortunately (I do actually agree), a > non-starter and not a realistic option for Fineract at the ASF. > > FYI I recently looked into this kind of topic in > https://issues.apache.org/jira/browse/LEGAL-462, which you may find > interesting to glance at in this context. There are, numerous, similar > other JIRA issues if you search for "LGPL" on > https://issues.apache.org/jira. > > >> Cheers, >> Isaac Kamga. >> >> [1] https://hibernate.org/community/license/ >> [2] https://www.apache.org/legal/resolved.html >> >> On Tue, Jul 9, 2019 at 11:08 PM Victor Manuel Romero Rodriguez < >> victor.rom...@fintecheando.mx> wrote: >> >>> Hello >>> >>> I will give my own opinions, by the way I don't work for any company >>> mentioned here :) >>> >>> For short: >>> >>> *I will keep using using Hibernate because it has advantages over the >>> others ORM listed. * >>> >>> >>> TL/TR >>> >>> The value of the core are the transactions recorded with confidence in a >>> Structured Database, the reliability of the Database is important, >>> customers can have their balances, their loans, investments, charges. The >>> audit guys will be happy to find in our journals the expected information. >>> The authorities will receive the reports that extract the information. >>> >>> Example: >>> >>> I got the source code of Fineract/Fineract-CN/Mifos and for some reason >>> the DataTable is not enough so then I need to modify the code... but I >>> don't not anything about the ORM technology,wait a minute I have some bucks >>> to pay a course at: >>> >>> Udemy (search results) >>> >>> 252 results for hibernate >>> 0 results for EclipseLink >>> 0 results for OpenJPA >>> 0 results for DataNucleus >>> >>> Ok, well now it is time to find some references in Google search engine >>> and learn about the ORM technology that Fineract/Fineract-CN/Mifos X uses >>> >>> Search results >>> >>> 2,350,000 hibernate >>> 138,000 OpenJPA >>> 74,900 EclipseLink >>> 15,400 DataNucleus >>> >>> Ok let's try to find the source code, have some references, samples (ok >>> just to learn, not to reuse because we can keep that in mind and later >>> affect the Open Source). >>> >>> Github (search results) >>> >>> 44,123 repositories hibernate >>> 478 repositories Eclipselink >>> 108 repositories OpenJPA >>> 142 repositories datanucleus >>> >>> After that I have touched the code and something goes wrong... yes, the >>> dev list of the ORM Technology is the first option, but what about to ask >>> to everybody at >>> >>> StackOverflow (search results) >>> >>> 78,304 Hibernate >>> 500 datanucleus >>> 500 openjpa (coincidence?) >>> 500 eclipselink (OK NO, StackOverflow has something strange in its >>> search engine) >>> >>> I consider that if the ORM technology is a MUST to be migrated, the ORM >>> team must be invited, involved, exchange experiences to feel the same pain >>> and help because it will benefit both projects. >>> >>> Regards >>> >>> Victor >>> On 7/1/19 1:47 a. m., Awasum Yannick wrote: >>> >>> Hi Graham, >>> >>> +1 EclipseLink as its supported by spring 4.x and latest spring versions >>> and compatible with Apache license. Our upgrade to Spring 5.x or 6.x will >>> be easier. >>> >>> We dont want to build and maintain our own integration of OpenJPA with >>> Spring 5 or 6 in the future. >>> >>> On Mon, Jul 1, 2019 at 7:40 AM Juhan Aasaru <aas...@gmail.com> wrote: >>> >>>> Hi! >>>> >>>> Good job starting the discussion. >>>> Based on your arguments I also see EclipseLink as the best solution. >>>> I also found one more argument for using EclipseLink - it supports >>>> multi-tenancy: >>>> >>>> https://www.eclipse.org/eclipselink/documentation/2.7/solutions/multitenancy.htm#CHDBJCJA >>>> >>>> Juhan >>>> >>>> Kontakt Ebenezer Graham (<ebenezergraha...@gmail.com>) kirjutas >>>> kuupäeval E, 1. juuli 2019 kell 07:09: >>>> >>>>> Hello Devs, >>>>> >>>>> I have started this thread to discuss the JPA implementation to adopt >>>>> as we work towards making Fineract CN Apache compliant as well as to >>>>> ensure >>>>> that we are all aligned as a community. >>>>> >>>>> I am currently working on the migration to OpenJPA as my GSoC project. >>>>> However, a number of red flags as well and requests from other community >>>>> members has made it critical to start this thread. >>>>> >>>>> As most of you know, we can't use Hibernate as it's not compliant >>>>> therefore, it's essential that we migrate to an equally good ORM. >>>>> >>>>> *Our options:* >>>>> 1. EclipseLink - EPL 1.0 & BSD >>>>> 2. OpenJPA - Apache 2.0 >>>>> 3. DataNucleus - Apache 2.0 >>>>> >>>>> Not recommended >>>>> 4. iBatic - Apache 2.0 (still functional but retired >>>>> https://ibatis.apache.org/) >>>>> 5. TopLink - CDDL (category B license, and simply extend EclipseLink) >>>>> >>>>> I used the following criteria in the following order of priority. >>>>> 1. License >>>>> 2. Implementation's performance with respect to PostgreSQL >>>>> 3. Support in Spring as well as ORM Documentation >>>>> 4. Project Maturity >>>>> >>>>> Right off the bat, I suggest the adoption of EclipseLink >>>>> <https://wiki.eclipse.org/EclipseLink> based on new insights >>>>> discovered, re-evaluation of our options, and compatibility issues >>>>> discovered whiles migrating to OpenJPA. >>>>> >>>>> *Why EclipseLink? * >>>>> According to JPA Performance benchmark - >>>>> http://www.jpab.org/All/All/All.html EclipseLink is the Most >>>>> Efficient ORM (amongst our valid options) when persisting to PostgreSQL >>>>> and >>>>> even outperforming Hibernate. >>>>> >>>>> Performance Summary (with respect to Postgres) >>>>> EclipseLink - 10.5 >>>>> Hibernate - 9.1 >>>>> OpenJPA - 6.5 >>>>> DataNucleus - 6.0 >>>>> >>>>> *Issues with OpenJPA.* >>>>> 1. Spring dropped support back in 2017 and requests to resume support >>>>> was declined earlier this year >>>>> https://github.com/spring-projects/spring-framework/issues/20584. >>>>> There is no guarantee when it will be back in newer versions of Spring. >>>>> Spring 5 for instance no longer includes the OpenJpaVendorAdaptor. >>>>> Therefore, future upgrade of Fineract CN will become an issue. >>>>> >>>>> 2. OpenJPA has been lagging behind - the stable version for spring >>>>> supports up to JDK 1.6 (although v3.0.0+ is working to resolve this >>>>> issue). >>>>> >>>>> 3. Bugs and compatibility issues with other libraries. I have >>>>> first-hand experience with it and it's not pleasant. >>>>> >>>>> *Why not DataNucleus?* >>>>> It is not supported in Spring 4.x and its implementation will require >>>>> us to completely heavily refactor the JPA Layer in Fineract CN on top of >>>>> that, it's the slowest. >>>>> >>>>> Looking forward to your recommendations and your own evaluations. >>>>> -- >>>>> >>>>> *Regards* >>>>> >>>>
