Yes, +1 for a 3.0.0 release in the near future. We run 'good enough' to be of use imo.
LieGrue, strub > Am 13.10.2017 um 10:37 schrieb Francesco Chicchiriccò <[email protected]>: > > Hi Michael, > sorry for the late reply and thanks for your appreciation! > > My 2c on the questions below, especially because I also have some interest in > being able to run a non-SNAPSHOT version of OpenJPA 3.0.0 with Syncope 2.1.0 > / Spring 5. > > AFAICT, the current trunk (e.g. 3.0.0-SNAPSHOT) already features some > interesting enhancements when compared to 2.4.x (e.g. 2.4.3-SNAPSHOT), > including Java 8 / JPA 2.1 compatibility, even though the implementation is > not yet complete. > > We also discussed [1] and decided [2] to move on with JPA 2.2 on trunk, and > to a recent inquiry [3] Mark suggested that the possibility of releasing soon > some kind of intermediate release is indeed possible. > > Even though the final 3.0.0, fully JPA 2.2 is possibly far in the future, > would it be realistic to consolidate what we have right now into a 3.0.0-M1 > release? > > Regards. > > [1] > https://lists.apache.org/thread.html/617c38ef8fb2a68075d17108c7329f1c03b47c30f4970f7a1b5ac11d@%3Cdev.openjpa.apache.org%3E > [2] https://issues.apache.org/jira/browse/OPENJPA-2709 > [3] > https://lists.apache.org/thread.html/51495df37e2e5038afa329fe46a807b6a637134bda7229cd6e0fb37e@%3Cdev.openjpa.apache.org%3E > > > On 11/10/2017 10:32, Michael Wiles wrote: >> Hi All >> >> As you know Spring 5 requires JEE7 as a minimum requirement. >> >> I am keen to upgrade to Spring 5 as I want to upgrade to Elastic search 5 >> and do do that we need Spring Data 2 for that and for that we need Spring 5. >> >> Let me say that I can only recommend openjpa. >> >> I say this because in my endeavours to upgrade to Spring 5 I switched to >> using Hibernate and cursed hibernate because it required that every getter >> had a corresponding setter (even if those methods had nothing to do with >> persistence) unless the existing method is annotated with @Transient. This >> rather ludicrous requirement disqualified hibernate in my eyes. >> >> Then I tried to eclipselink and again my app did not start because the >> Spring Data meta model generating failed. Something to do with having >> Spring data repositories on composite keys (I have a lot of these) - >> notwithstanding the fact that I had to build my own version of eclipselink >> because I got a stackoverflow because I use an annotation that was >> annotated with itself (and they support meta annotations). >> >> What is interesting is that I used the 3.0.0-SNAPSHOT branch of Openjpa in >> my code and was able to run some of my integration tests successfully on >> Spring 5. >> >> So given all the above, I am unwilling to migrate to hiberate or >> eclipselink - this I do not want to do. >> >> I'm sorry to ask such a blunt question: When will a JPA 2.1 compliant >> version of openjpa be ready? I guess I would like some indication about >> whether it will weeks, months or years? >> >> In this regard, what can I do to help? I do not want to switch to hibernate >> or eclipselink so I would be willing to help where I can... I'm not sure >> I'd be able to do some of the more hard core stuff - although I do get up >> close and personal with the low level code from time to time - but I could >> help with testing and/or documentation... I do have a fairly robust >> application which does use a lot of the jpa specification. >> >> Thank you - and thanks again for what I think is the best JPA >> implementation around. >> >> Michael > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Member at The Apache Software Foundation > Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail > http://home.apache.org/~ilgrosso/ >
