Hmm, not exactly what i expected but it should work, not just as transparent and integrated as i thought.
The end of the dependency mess is still key for me and only this jar can justify the scope compile you spoke about, all G one should be provides IMHO. Dont think osgi is a blocker while you dont put it in the karaf feature. So tempted to say you can finish the pr. Le mar. 17 déc. 2019 à 07:06, Maxim Solodovnik <[email protected]> a écrit : > This is part of MANIFEST.MF > > Bundle-ManifestVersion: 2 > Bundle-Vendor: Eclipse.org - EclipseLink Project > Require-Capability: osgi.ee; filter:="(&(osgi.ee=JavaSE)(version>=1.8) > )" > Import-Package: javax.sql;resolution:=optional,org.osgi.framework;reso > lution:=optional,org.osgi.service.jpa;version="1.1.0" > Implementation-Vendor: Eclipse.org - EclipseLink Project > Export-Package: javax.persistence;jpa="2.2";version="2.2.3",javax.pers > istence.criteria;jpa="2.2";version="2.2.3",javax.persistence.metamode > l;jpa="2.2";version="2.2.3",javax.persistence.spi;jpa="2.2";version=" > 2.2.3",org.osgi.service.jpa;version="1.1.0" > Bundle-Name: Jakarta Persistence API 2.2 > Bundle-Version: 2.2.3 > Bundle-ClassPath: . > Bundle-Activator: org.eclipse.persistence.javax.persistence.osgi.Activ > ator > > I was unable to find "Provide-Capability" in the jar (but maybe I was > looking in wrong place ...) > > On Tue, 17 Dec 2019 at 12:58, Romain Manni-Bucau <[email protected]> > wrote: > > > > Hmmm, looks like old style, doesnt it have Provide-Capability somewhere > > (sorry i dont have a computer handy right now)? > > Maybe reopen a thread @g Mark if you want to do that, but we should also > > include micrporofile in that thread to enforce our consistence IMHO. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le mar. 17 déc. 2019 à 06:56, Maxim Solodovnik <[email protected]> a > > écrit : > > > > > I'm not familiar with OSGI > > > jakarta.jas has `Activator implements > org.osgi.framework.BundleActivator` > > > and `OSGiProviderResolver implements PersistenceProviderResolver, > > > PersistenceProvider` > > > > > > Please let me know if I should proceed with my PR, or if it would be > > > better to dismiss it :) > > > > > > On Tue, 17 Dec 2019 at 04:42, Romain Manni-Bucau < > [email protected]> > > > wrote: > > > > > > > > Le lun. 16 déc. 2019 à 22:13, Mark Struberg > <[email protected]> > > > a > > > > écrit : > > > > > > > > > jakarta persistence is EPL. It's not a problem to add it but would > > > love to > > > > > avoid it. > > > > > The simplest way would be to add those module information to > > > Geronimo-jpa. > > > > > Could do a mass release of those specs then. > > > > > > > > > > > > > We should stick to a single strategy for all spec jars with a > compatible > > > > license IMHO. > > > > I dont care which way we go but I dont want a case by case choice > which > > > > would be hard to support. > > > > > > > > Also having jakarta deps will reduce dependency management for post > users > > > > so i see it as a 60-40 for jakata. > > > > > > > > > > > > > LieGrue, > > > > > strub > > > > > > > > > > > > > > > > Am 16.12.2019 um 14:39 schrieb Maxim Solodovnik < > > > [email protected]>: > > > > > > > > > > > > Here is the diff > > > > > > > > > https://github.com/apache/openjpa/compare/OPENJPA-2798-java11-friendly > > > > > > > > > > > > On Mon, 16 Dec 2019 at 20:38, Maxim Solodovnik < > [email protected] > > > > > > > > > wrote: > > > > > >> > > > > > >> Current status: In my branch I have changed jpa_spec with > > > > > >> jakarta.persistence and the build is green > > > > > >> I can drop this branch if there is better way to achieve java11 > > > > > compatibility :) > > > > > >> > > > > > >> I always thought modules is like dependencies > > > > > >> I only have openjpa dependency right now and do have all > transitive > > > > > >> jars available, so my pom is cleaner ... > > > > > >> > > > > > >> On Mon, 16 Dec 2019 at 20:32, Mark Struberg > > > <[email protected]> > > > > > wrote: > > > > > >>> > > > > > >>> I'm not sure what the status is right now. But one of the big > pros > > > > > over the standard jpa api has always been that it works even with > OSGi. > > > > > >>> > > > > > >>> LieGrue, > > > > > >>> strub > > > > > >>> > > > > > >>> > > > > > >>>> Am 16.12.2019 um 14:24 schrieb Romain Manni-Bucau < > > > > > [email protected]>: > > > > > >>>> > > > > > >>>> Not "compile time dependencies" but "spec jars". Mainly > because > > > the > > > > > user > > > > > >>>> must import it himself (this is what he use to code so it > should > > > be a > > > > > first > > > > > >>>> level dep + to avoid the exclusion mess since there are like > 6-7 > > > spec > > > > > jars > > > > > >>>> libs use and conflict). > > > > > >>>> > > > > > >>>> Romain Manni-Bucau > > > > > >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > >>>> <https://rmannibucau.metawerx.net/> | Old Blog > > > > > >>>> <http://rmannibucau.wordpress.com> | Github < > > > > > https://github.com/rmannibucau> | > > > > > >>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > > >>>> < > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > >>>> > > > > > >>>> > > > > > >>>> Le lun. 16 déc. 2019 à 14:15, Maxim Solodovnik < > > > [email protected]> > > > > > a > > > > > >>>> écrit : > > > > > >>>> > > > > > >>>>> BTW why compile time dependency should't be transitive? > > > > > >>>>> > > > > > >>>>> On Mon, 16 Dec 2019 at 20:12, Maxim Solodovnik < > > > [email protected] > > > > > > > > > > > >>>>> wrote: > > > > > >>>>>> > > > > > >>>>>> I can create PR in a minute (based on > > > OPENJPA-2798-java11-friendly > > > > > >>>>> branch) > > > > > >>>>>> Was planning to add "Automatic-Module-Name"s to manifest > > > > > >>>>>> > > > > > >>>>>> On Mon, 16 Dec 2019 at 20:03, Romain Manni-Bucau < > > > > > [email protected]> > > > > > >>>>> wrote: > > > > > >>>>>>> > > > > > >>>>>>> Nobody uses it but adding them breaks apps ;), yeah. > > > > > >>>>>>> Anyway openjpa shouldnt have jpa api transitive anyway > IMHO so > > > not > > > > > a > > > > > >>>>> big > > > > > >>>>>>> deal while we dont break OSGi case in the feature.xml. > > > > > >>>>>>> > > > > > >>>>>>> Romain Manni-Bucau > > > > > >>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > >>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog > > > > > >>>>>>> <http://rmannibucau.wordpress.com> | Github < > > > > > >>>>> https://github.com/rmannibucau> | > > > > > >>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > > >>>>>>> < > > > > > >>>>> > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > >>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> Le lun. 16 déc. 2019 à 13:52, Mark Struberg > > > > > <[email protected]> > > > > > >>>>> a > > > > > >>>>>>> écrit : > > > > > >>>>>>> > > > > > >>>>>>>> I'd go with fixing our module info in geronimo-jpa. > > > > > >>>>>>>> > > > > > >>>>>>>> But otoh nobody is using modules anyway it seems ... > > > > > >>>>>>>> > > > > > >>>>>>>> LieGrue, > > > > > >>>>>>>> strub > > > > > >>>>>>>> > > > > > >>>>>>>>> Am 11.12.2019 um 06:39 schrieb Romain Manni-Bucau < > > > > > >>>>> [email protected] > > > > > >>>>>>>>> : > > > > > >>>>>>>>> > > > > > >>>>>>>>> Yes this one > > > > > >>>>>>>>> > > > > > >>>>>>>>> For openjpa the challenge will likely to not have > > > module-info in > > > > > >>>>> main > > > > > >>>>>>>>> artifacts - guess we can duplicate artifacts with a > > > classifier > > > > > >>>>> jpms or > > > > > >>>>>>>> so - > > > > > >>>>>>>>> to avoid to break some servers and env. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Last thing to take care: all osgi integration, i didnt > check > > > > > >>>>> jakarta jar > > > > > >>>>>>>>> supports it as well as our spec jar. > > > > > >>>>>>>>> > > > > > >>>>>>>>> So likely some validation work to do but yes it sounds > like > > > the > > > > > >>>>> plan. > > > > > >>>>>>>>> > > > > > >>>>>>>>> Hope it helps even if not a straight "yes". > > > > > >>>>>>>>> > > > > > >>>>>>>>> Le mer. 11 déc. 2019 à 03:57, Maxim Solodovnik < > > > > > >>>>> [email protected]> a > > > > > >>>>>>>>> écrit : > > > > > >>>>>>>>> > > > > > >>>>>>>>>> Do you mean this one: > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> <dependency> > > > > > >>>>>>>>>> <groupId>org.eclipse.persistence</groupId> > > > > > >>>>>>>>>> <artifactId>jakarta.persistence</artifactId> > > > > > >>>>>>>>>> <version>2.2.2</version> > > > > > >>>>>>>>>> </dependency> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Looks good to me! > > > > > >>>>>>>>>> Shall I create PR? (the task seems to be doable for me > :))) > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> On Wed, 11 Dec 2019 at 01:03, Romain Manni-Bucau < > > > > > >>>>> [email protected] > > > > > >>>>>>>>> > > > > > >>>>>>>>>> wrote: > > > > > >>>>>>>>>> > > > > > >>>>>>>>>>> Hi > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> I proposed some time ago to rename them all but since > > > jakarta > > > > > is > > > > > >>>>> at > > > > > >>>>>>>>>> eclipse > > > > > >>>>>>>>>>> now, i guess well more move to their bundles. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Wdyt? > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Le mar. 10 déc. 2019 à 18:18, Maxim Solodovnik < > > > > > >>>>> [email protected]> > > > > > >>>>>>>> a > > > > > >>>>>>>>>>> écrit : > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>>> Hello All, > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> not sure which list should I ask, so will start here > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> I have started to add module-info to our project > > > > > >>>>>>>>>>>> The issue I found is: > > > > > >>>>>>>>>>>> openjpa depends on "Apache Geronimo JPA Spec 2.2" > > > > > >>>>>>>>>>>> geronimo jpa doesn't have automatic module name and > > > > > >>>>> automatically > > > > > >>>>>>>> being > > > > > >>>>>>>>>>>> resolved as > > > > > >>>>>>>>>>>> geronimo.jpa.2.2.spec > > > > > >>>>>>>>>>>> Which is invalid java identifier :((( > > > > > >>>>>>>>>>>> Maybe it would be possible to release same artifact > with > > > some > > > > > >>>>> correct > > > > > >>>>>>>>>>>> module name for ex. `geronimo.jpa_2_2.spec` and with > > > > > >>>>> incremented micro > > > > > >>>>>>>>>>>> version? > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> Or maybe there are other options I\, not aware of? > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> -- > > > > > >>>>>>>>>>>> WBR > > > > > >>>>>>>>>>>> Maxim aka solomax > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> -- > > > > > >>>>>>>>>> WBR > > > > > >>>>>>>>>> Maxim aka solomax > > > > > >>>>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> -- > > > > > >>>>>> WBR > > > > > >>>>>> Maxim aka solomax > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> -- > > > > > >>>>> WBR > > > > > >>>>> Maxim aka solomax > > > > > >>>>> > > > > > >>> > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> WBR > > > > > >> Maxim aka solomax > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > WBR > > > > > > Maxim aka solomax > > > > > > > > > > > > > > > > > > > > > > -- > > > WBR > > > Maxim aka solomax > > > > > > > -- > WBR > Maxim aka solomax >
