If you have enough cycles i would be for simplifying all that but can't really help myself these days so kind of +0
PS: thought exactly that while working on stored proc on 2.1 branch Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2017-07-25 18:53 GMT+02:00 Mark Struberg <[email protected]>: > We do have the 1.4.x branch for JPA-2.0. > There is quite a bit of work to do for JPA-2.1 to be functional. > And while trying to upgrade to Java8 I came across stuff I have long moved > out of my mind. > > E.g. is the abstraction of the Broker still important those days? > I used Kodo back in early 2k. And Kodo was the base for OpenJPA. But is > JDO still on the roadmap for OpenJPA? > Is there some project which extends the openjpa broker with a JDO frontend? > > Or does our great modular structur only exist in theory? > > While trying to upgrade our -source and -target to Java8 I came across a > few ugly compat issues. > > In many classes in openjpa-kernel we have a OrderedMap<Object, Class<?>>. > Mostly for Parameters. > That worked fine in Java7, but Java8 complains that you cannot cast it to > OrderedMap<ParameterExpression<?>, Class<?>> (CriteriaQueryImpl#410). > > While digging deeper I tried to extract the necessary parts, extract into > real generics etc. > By doing so I came across many JPQL related parts in openjpa-kernel. > > Why are those JPQL parts in openjpa-kernel? > And now back to my initial question: does this separation and abstraction > layer still make sense at all? > Currently we fool ourselves in having an 'abstract'. But this core > contains very JPA specific things. And then we upcast from Object to > ParameterExpression... > > Do we go one step further and do a REALLY deep cleanup? > We don't need to be afraid imo. WAS and TomEE have stable maintenance > versions. > And we need to either innovate/cleanup or we loose anyway. > > LieGrue, > strub > > > > > Am 25.07.2017 um 18:32 schrieb Kevin Sutter <[email protected]>: > > > > Yep, sounds like the right plan of attack. Just for posterity and the > > potential for a 2.1 release down the road, maybe you want to cut a > > "sandbox" branch for the 2.1 development? And, then declare trunk as > 2.2? > > > > -- Kevin > > > > On Mon, Jul 24, 2017 at 1:16 PM, Romain Manni-Bucau < > [email protected]> > > wrote: > > > >> +1 > >> > >> Le 24 juil. 2017 20:01, "Francesco Chicchiriccò" <[email protected]> > a > >> écrit : > >> > >>> Mark Struberg <[email protected]> wrote: > >>>> Hi! > >>>> > >>>> The JPA-2.2 spec is out and and only contains minor changes over 2.1. > >>>> I already noted in the board report that it might make sense to > >> directly > >>> move to JPA-2.2 in trunk. > >>>> Because finishing an obsoleve version is probably not worth it. > >>>> We imo better focus on getting 2.2 done. > >>>> > >>>> Wdyt? > >>> > >>> +1, go ahead. > >>> Regards. > >>> > >> > >
