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
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
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
"(&(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
-
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
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
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
Hi Randy,
the code complains that the interface
com.sun.xml.internal.ws.developer.WSBindingProvider is not visible.
This possibly means that standard JAXWS from the JDK is used to create
the service proxy.
I think the reason is that the generated code for the client class uses
the JAXWS
On 15.09.2016 09:19, Randy Leonard wrote:
Christian:
Thanks for the head’s up on your work with DOSGi… I’ll certainly take a look.
I just started the vote for CXF DOSGi 2.0.0 yesterday. So this would be
a good chance to look into it. See the vote thread on the cxf dev list.
It should also be
Christian:
Thanks for the head’s up on your work with DOSGi… I’ll certainly take a look.
What I’ve built to-date is the following:
- Contract-first development with hand-written wsdl's, then using an Eclipse
plugin to generate annotated code
- Leverage these contracts and auto-generated code
10 matches
Mail list logo
