[
https://issues.apache.org/jira/browse/ARIES-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821523#comment-13821523
]
Timothy Ward commented on ARIES-1134:
-------------------------------------
Hi Albert,
I can absolutely understand why the version ranges seem wrong. Semantic
versioning can be quite confusing at times, and the way in which the JPA API
versions have changed over time makes things even worse.
For background:
The correct OSGi version range for a package import depends on who is importing
the package and why. If you are a consumer of the API (e.g you are using an
EMF, or writing a Servlet) then you use a "consumer version range". This means
that you import from the version you compile against up to (but not including)
the next major version. If you are a provider of an API (e.g. you are
Jetty/TomCat or you are OpenJPA) then you have to have a smaller version range,
being the version you compile against up to (but not including) the next minor
version.
This is covered in more detail here:
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
Versioning the JPA API
The JPA API is defined and maintained through the JCP, and does not observe
semantic versioning. Semantically speaking, as all of the JPA releases are
backward compatible, the correct JPA versions are 1.0, 1.1 (released as 2.0)
and 1.2 (released as 2.1). This means that the JPA API bundles should be
exporting the javax.persistence package at version 1.0, 1.1 or 1.2.
Unfortunately the "big players" simply released bundles using the "marketing
version" from the spec. This means that we have to cope with unpleasant things
when writing JPA containers to avoid end users complaining.
Looking at Aries JPA:
In Aries JPA there are a number of different bundles that do different things.
The Aries JPA API. This is a bundle containing the API for interacting directly
with the JPA container. This doesn't provide any javax.persistence.* types, so
it could use a client range.
The JPA container bundle does the core "container managed" work, finding
Persistence bundles and creating EMFs. The JPA container bundle actually has to
wrap the EMFs that come out, making it a provider of the JPA API (see
DelegatingEntityManagerFactory.java). It therefore has to have a "provider
version range", which would normally be [1.1,1.2) or [2.0,2.1). As a
requirement from previous users, the Aries JPA container actually supports both
JPA 1.0 and JPA 2.0 (we have tests for both). This means that we have to be
careful to write the bundle in a way that it can provide implementations that
work properly regardless.
The JPA container context does the "Managed Persistence Context" part of the
JPA container work. This also has to implement the JPA API (EntityManager) and
is therefore also an API provider. This has similar requirements, and must be
able to work when wired to both parts of the API.
The JPA blueprint integration does the Aries JPA namespace for blueprint. This
uses the JPA API, but as a client, so it gets a broader version range to import.
Next steps for the patch:
Updating the versions of the package imports is only a small part of updating
the Aries JPA project for JPA 2.1. The bundles need to be compiled against the
new JPA API. All of the implementations of JPA API interfaces need to be
updated to add new methods/types. The Persistence Descriptor Parser needs to be
updated to support the new XML format. New tests need to be added to show that
the JPA container works when wired to the JPA 2.1 API (which doesn't
necessarily mean using the new JPA API methods). Existing tests need to be
maintained/run to be sure that the JPA container bundles still work with JPA
1.0 and JPA 2.0.
I hope this helps - this is something I have been planning to do for a while,
but unfortunately I have less time for Aries JPA than I used to. Contributions
are definitely welcome, I'm just sorry I didn't reach this JIRA item before the
first commit!
Regards,
Tim
> Enable JPA 2.1 API and correct inconsistent <aries.osgi.import> versioning
> --------------------------------------------------------------------------
>
> Key: ARIES-1134
> URL: https://issues.apache.org/jira/browse/ARIES-1134
> Project: Aries
> Issue Type: Improvement
> Components: Blueprint, JPA
> Reporter: Albert Lee
> Priority: Minor
> Attachments: ARIES-1134.patch
>
>
> There are some inconsistency of <aries.osgi.import> version useage between
> these modules:
> jpa/jpa-api/pom.xml
> jpa/jpa-container/pom.xml
> jpa/jpa-container-context/pom.xml
> jpa/jpa-container-eclipselink-adapter/pom.xml
> javax.persistence;version="[1.0.0,2.1.0)",
> javax.persistence.spi;version="[1.0.0,2.1.0)",
> javax.persistence.criteria;version="[1.1.0,2.1.0)";
> javax.persistence.metamodel;version="[1.1.0,2.1.0)";
> and
> jpa-blueprint-aries/pom.xml
> javax.persistence;version="[1.0.0,3.0.0)",
> I would like to propose all these modules' version updated to
> javax.persistence;version="[1.0.0,3.0.0)",
> so the JPA 2.1 API can be used at runtime, if enabled by the container
> environment.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
