On Wed, Jul 10, 2019 at 8:43 AM Isaac Kamga <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 (<[email protected]>) 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* >>>> >>>
