[iot-pmc] [CQ 21907] org.hibernate:hibernate-core:5.0.12

[emo-ip-team@xxxxxxxxxxx]

http://dev.eclipse.org/ipzilla/show_bug.cgi?id=21907





--- Comment #14 from Kevin Olotu <kevin.olotu@xxxxxxxx>  2020-05-25 03:22:10 ---
(In reply to comment #12)
> (In reply to comment #10)
> > > Then it looks like this slipped through the IP log review ...
> > 
> > I'm disappointed that I missed this in past reviews. Based on the date of the
> > last IP Log review, I must have based my approval on the project downloads (the
> > 0.12.0 release does not contain this library). 
> > 
> > How do consumers of the 0.12.0 release obtain this content?
> > 
> > Our new tools are based around the build, which gives us a much broader view of
> > the actual dependencies.
> > 
> > To manage expectations, note that the EMO review of an IP Log is intended as a
> > sanity check, not as an authoritative declaration.
> > 
> > > @Wayne: how should we proceed here? It looks like we have Vorto releases out
> > > there in the wild which contain Hibernate artifacts for which there is no
> > > approved CQ. I see two options:
> > > 1. we get (retroactive) board approval for using Hibernate
> > > 2. we live with that fact but replace Hibernate with e.g. EclipseLink
> > 
> > That the library is a dependency of a dependency leads me to believe that
> > replacing it is going to be hard (it would be great to see the Spring Data
> > component use EclipseLink instead, but that's going to take time).
> 
> 
> Well, it actually shouldn't be a big issue to replace Hibernate with
> EclipseLink as the JPA provider. Assuming, that the application indeed is built
> on top of JPA and not Hibernate ...
> 
> [1] https://www.codeflow.site/de/article/spring-eclipselink
> [2]
> https://blog.marcnuri.com/spring-data-jpa-eclipselink-configuring-spring-boot-to-use-eclipselink-as-the-jpa-provider/
> 
> > 
> > My recommendation is that the PMC approve this CQ and ask the IP Team to
> > initiate the process of seeking board approval to use the content under the
> > current license.
> 
> FMPOV the project team should do some experiments regarding replacing the JPA
> provider first. Base on the outcome the board might still need to "sanction"
> the use of Hibernate in already released versions ...
> 
We have completed some experiments with EclipseLink as JPA implementation and
we ran into a couple difficulties, among which the most troubling one are
severe performance issues that prevent the integration tests from completing
and apart from that some corrupted data in the test database that we used. Also
literature on running Spring with EclipseLink instead of Hibernate is very thin
at best. Therefore we expect that it would take a quite considerable amount of
effort to make it work, with an uncertain outcome. 

Question is, how should we proceed here? I personally would prefer to keep
Hibernate in place if possible. WDYT?

> > 
> > IP Team: I am aware of at least one other project that is in a very similar
> > situation, so my recommendation is that we ask the board for the broadest
> > approval possible. It's likely that they will want us to approve this on a
> > project-by-project basis, but we should ask for "all projects".
> > 
> > Since, AFAICT the project is not actively distributing the content in question
> > from our download server, I suggest that we wait for the board's decision to
> > decide what to do with the older downloads.
> > 
> 


-- 
Configure CQmail: http://dev.eclipse.org/ipzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the CQ.