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:
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
http://bnd.bndtools.org/chapters/220-contracts.html). Contracts are
the only reliable way for clients to deal with the inconsistent JSR
versioning policies.
*I’m writing the following section because I know that Christian is
also an implementor, and so needs to work out how to deal with the JPA
provider side too. The information below is not needed by people who
just want to use JPA in their applications.*
Contracts work well for consuming the API in a client, but the
requirement for providers that want substitutability (or just to use
an external API bundle) is harder and I don’t think bnd helps much. To
be substitutable you would need to write the contract so that you
import the correct version, but not any version higher than that
(otherwise clients may get NoSuchMethodErrors when trying to call API
from higher versions.
The following is my best guess at how to make the maximum number of
things work!
The requirement filter looks very odd, and is expressed as follows
(&(osgi.contract=JavaJPA)(version=2.1)(version<=2.1)):
For substitutable JPA 2.1 that works with current EclipseLink and
Hibernate releases the metadata needs to be:
Export-Package:javax.persistence; javax.persistence.criteria;
javax.persistence.metamodel; javax.persistence.spi;version=2.1.0;jpa=2.1
Import-Package: javax.persistence, javax.persistence.criteria,
javax.persistence.metamodel, javax.persistence.spi
Require-Capability:
osgi.contract;filter:=“(&(osgi.contract=JavaJPA)(version=2.1)(version<=2.1))”
Provide-Capability:
osgi.contract:osgi.contract=JavaJPA;version:Version=2.1;uses:=“javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi”,
osgi.contract:osgi.contract=JavaJPA;version:Version=2.0;uses:=“javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi”,
osgi.contract:osgi.contract=JavaJPA;version:Version=1.0;uses:=“javax.persistence,javax.persistence.spi”
For substitutable JPA 2.0 that works with OpenJPA, and older
EclipseLink and Hibernate releases:
Export-Package:javax.persistence; javax.persistence.criteria;
javax.persistence.metamodel; javax.persistence.spi;version=2.0.0;jpa=2.0
Import-Package: javax.persistence, javax.persistence.criteria,
javax.persistence.metamodel, javax.persistence.spi
Require-Capability:
osgi.contract;filter:=“(&(osgi.contract=JavaJPA)(version=2.0)(version<=2.0))”
Provide-Capability:
osgi.contract:osgi.contract=JavaJPA;version:Version=2.0;uses:=“javax.persistence,javax.persistence.criteria,javax.persistence.metamodel,javax.persistence.spi”,
osgi.contract:osgi.contract=JavaJPA;version:Version=1.0;uses:=“javax.persistence,javax.persistence.spi”
This is what Aries JPA and Transaction Control need to do when
providing the JPA API, and it will be described in the upcoming JPA
Service update.
Note that all of this will probably still not help with JPA providers
that have even crazier import ranges, but we do what we can.
Regards,
Tim
On 15 Sep 2016, at 05:15, David Bosschaert
<david.bosscha...@gmail.com <mailto:david.bosscha...@gmail.com>> wrote:
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
Require-Capability: osgi.contract;
filter:="(&(osgi.contract=JavaJPA)(version=2.1))"
Note that the Import-Package in this case has no version associated
with the packages. This is because there is no agreed semantic
versioning associated with these packages. So providers of the JPA
package can version these using whatever schema they want.
Consumers bind to the specific version of JPA via the
Require-Capability which specifies the exact version needed (not a
range). Implementations list all the version numbers of the JSR-spec
that they are compatible with. For more info see [1] and [2].
Obviously this only works when the OSGi-JPA provider implementation
supports osgi.contract by providing the JavaJPA capability for all
the versions that it is compatible with (1, 2 and 2.1). For older
OSGi-JPA implementations this may not be the case as it may be that
they predate the osgi.contract namespace...
Best regards,
David
[1]
http://blog.osgi.org/2014/09/portable-java-contracts-for-javax.html
<http://blog.osgi.org/2014/09/portable-java-contracts-for-javax.html>
[2] https://www.osgi.org/portable-java-contract-definitions/
<https://www.osgi.org/portable-java-contract-definitions/>
On 15 September 2016 at 12:31, Christian Schneider
<ch...@die-schneider.net <mailto:ch...@die-schneider.net>> wrote:
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
javax.persistence;jpa="2.1";version="2.1.0"
org.apache.geronimo.specs:geronimo-jpa_2.1_spec:1.0-alpha-1 has
javax.persistence;jpa="2.1";version="1.2"
Which of these is correct?
How would a client correctly express the dependency to the jpa
2.0 or 2.1 API?
I see that there is also jpa=2.1 on the package export. Can the
be used to describe the import?
Currently I use a version range of [2.1,2.2) in my own code. Not
sure if this is correct.
I think it would also make sense to recommend specific maven
coordinates for each persistence spec as a kind of offical spec
bundle to use. Elese people might choose the wrong and end up
with broken imports.
Christian
On 08.07.2016 15:41, Christian Schneider wrote:
Done
https://osgi.org/bugzilla/show_bug.cgi?id=189
<https://osgi.org/bugzilla/show_bug.cgi?id=189>
Christian
On 08.07.2016 14:49, Raymond Auge wrote:
Christian could you file a bug on the public OSGi
bugzilla so we don't forget to fix this?
I wonder if the spec bundle should refer to
javax.persistence via Portable Java Contract rather then
by package version. We have a similar issue with the
org.osgi.service.http bundle which I believe should also
refer to a PJC for javax.servlet.
https://osgi.org/bugzilla/buglist.cgi
<https://osgi.org/bugzilla/buglist.cgi>
- Ray
--
Christian Schneider
http://www.liquid-reality.de <http://www.liquid-reality.de/>
Open Source Architect
http://www.talend.com <http://www.talend.com/>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
<https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
