Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

> > I agree with Christian that this should be clearly documented in a wiki > somewhere. Please someone, DO document this! I already moved this thread to my "Things about OSGi that you need to read at least 5 times before they start making sense" folder :) but for anyone not on this list, it

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

I would definitely support this - I’m not sure how else to make bundles that implement contracts work reliably, and that impacts users too. Regards, Tim > On 16 Sep 2016, at 08:26, Thomas Watson wrote: > > Regardless, should the best practice for providing osgi.contract

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

I agree with Christian that this should be clearly documented in a wiki somewhere. My personal opinion is that a bare-bones enroute JPA example would be a good place for this. Elliot On Fri, Sep 16, 2016 at 9:26 AM, Thomas Watson wrote: > Regardless, should the best

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

Regardless, should the best practice for providing osgi.contract capabilities be to only provide one capability per osgi.contract name? And use Lists for attributes where you want to express multiple version support? I know for a fact there are Servlet 2.5 applications that will simply break

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

What do you think about writing a wiki page about this. So people can find this information more easily. I think we should also recommend certain maven bundles that provide each persistence api. Would enroute be a good place for such a page? Christian On 15.09.2016 20:12, Timothy Ward wrote:

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

As Tom mentions, when a bundle provides multiple contracts, the filter of the requirement only has to match one of the contracts. So adding an additional filter _expression_ like (version<=2.1) does not exclude the bundle which also offers the contract at version=3.   As an implementation bundle,

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

I think we have opened an old discussion. But I don't recall why things have ended up where they are with recommending multiple osgi.contract version capabilities from the same bundle that exports the packages. So from https://www.osgi.org/portable-java-contract-definitions/ it states the

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

BJ - My understanding is that contract versions don’t work like normal semantic versions (if only they did…) and that version 2.0.1 may be totally incompatible with version 2.0.0. I therefore don’t think it’s safe to use a range like “[2.1,2.2)”. My understanding of their intended use is that

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

But they are anded. So version=2.1 is the range[2.1,2.1]. This second range for version<=2.1 is [0,2.1]. So the intersection of those ranges is exactly 2.1. So the _expression_ version<=2.1 adds no value.   If you want the range [2.1,2.2) then your filter _expression_ is

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

That was my intention. If I am a provider of version 2.1 of the JPA API then I need access to types defined in JPA 2.1, hence the (version=2.1). As a provider of the JPA API I also need to guarantee that I don’t wire to some future, backward-compatible version of the JPA API packages, as I

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

"(&(osgi.contract=JavaJPA)(version=2.1)(version<=2.1))" will only match exactly version 2.1 since the next term is anded.     --BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com     -

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

Hi Christian, Yes, this is a mess, and yes, it is hard. The JSR process has done a good job of making versioning as hard as possible! For some extra help, bnd will do the contract import for your consumer if you use the -contract instruction (see

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

Hi Christian, The portable contracts define how you should do your imports with JSR-based APIs, since they often don't follow semantic versioning. What should really be done is: Import-Package: javax.persistence, javax.persistence.criteria, javax.persistence.metamodel, javax.persistence.spi

Re: [osgi-dev] The JPA spec bundle does not work with jpa 2.1

Unfortunately the spec only defines the jpa package properties up to jpa 2.0. Do the OSGi specs already define JPA 2.1 somewhere? I just checked some of the JPA API bundles and they provide very different package versions. org.eclipse.persistence:javax.persistence:2.1.0 has

[osgi-dev] The JPA spec bundle does not work with jpa 2.1

I am using the jpa spec bundle from |<||dependency||>| |||<||groupId||>org.osgi| |||<||artifactId||>org.osgi.service.jpa| |||<||version||>1.0.0| || Unfortunately it does not work with jpa 2.1. The error is: missing requirement [org.osgi.service.jpa/1.0.0.201505202024] osgi.wiring.package;