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 <rmannibu...@gmail.com> 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 <solomax...@gmail.com> 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 <rmannibu...@gmail.com> > > wrote: > > > > > > Le lun. 16 déc. 2019 à 22:13, Mark Struberg <strub...@yahoo.de.invalid> > > 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 < > > solomax...@gmail.com>: > > > > > > > > > > Here is the diff > > > > > > > https://github.com/apache/openjpa/compare/OPENJPA-2798-java11-friendly > > > > > > > > > > On Mon, 16 Dec 2019 at 20:38, Maxim Solodovnik <solomax...@gmail.com > > > > > > > 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 > > <strub...@yahoo.de.invalid> > > > > 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 < > > > > rmannibu...@gmail.com>: > > > > >>>> > > > > >>>> 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 < > > solomax...@gmail.com> > > > > a > > > > >>>> écrit : > > > > >>>> > > > > >>>>> BTW why compile time dependency should't be transitive? > > > > >>>>> > > > > >>>>> On Mon, 16 Dec 2019 at 20:12, Maxim Solodovnik < > > solomax...@gmail.com > > > > > > > > > >>>>> 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 < > > > > rmannibu...@gmail.com> > > > > >>>>> 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 > > > > <strub...@yahoo.de.invalid> > > > > >>>>> 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 < > > > > >>>>> rmannibu...@gmail.com > > > > >>>>>>>>> : > > > > >>>>>>>>> > > > > >>>>>>>>> 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 < > > > > >>>>> solomax...@gmail.com> 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 < > > > > >>>>> rmannibu...@gmail.com > > > > >>>>>>>>> > > > > >>>>>>>>>> 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 < > > > > >>>>> solomax...@gmail.com> > > > > >>>>>>>> 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
