[JPA_SPEC-60] Upload official/standard JPA 2.1 API jar to Maven Central Created: 13/Jun/13  Updated: 07/Feb/14  Due: 22/May/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Matthew Adams Assignee: Unassigned
Resolution: Unresolved Votes: 26
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven, osgi, repositories


There is no official or standard JPA API jar available from the expert group in either Maven Central or the java.net Maven repo that both JPA users & implementors can utilize. Users are left to search for implementations' groupId, artifactId, & version values, which is inconvenient.

Please upload a binary jar (including class files and relevant resource files), a source jar, and a javadoc jar, under the groupId "javax.persistence", artifact id "jpa-api" and version "2.1". A minimal target Maven repository would be Maven Central, but others like java.net might be nice, too.

Bonus points for including OSGi bundle metadata (pretty easy if using Apache Felix's Maven Bundle Plugin, org.apache.felix:maven-bundle-plugin:2.3.7)!

Comment by Matthew Adams [ 13/Jun/13 ]

This issue is the same as https://java.net/jira/browse/JPA_SPEC-19 except for JPA 2.1.

Comment by datanucleus [ 13/Jun/13 ]

Since when has an implementation had to provide their own variant of the "standard" API jar? Such a basic thing ought to be a prerequisite of the JSR to have that as one of its deliverables and the JSR not considered "complete" til its done, just like the spec and TCK (and add to that publishing of XSD/DTDs on a public site). Or maybe its just another way to keep it all "secret" (like that mystical TCK) ...

Comment by Matthew Adams [ 13/Jun/13 ]


Is this intended to be the release? If so, it might do for some, but a standalone JPA API artifact would be ideal.

Comment by neilstockton [ 14/Nov/13 ]

Seems like voting on this JIRA is not looked at by the people behind JPA, evidently not interested in what the majority of people want.

Comment by Oliver Gierke [ 07/Feb/14 ]

I'd also like to vote to finally introduce a canonical API JAR. We're currently seeing a lot of users running into classpath issues for the following reasons:

Persistence providers historically shipped their own packaged API versions. For libraries trying to build on top of JPA this created the unfortunate situation that they had to refer to a persistence provider provided API JAR which subverts the provider independence of the library.

Even worse, as the providers get access to the API JARs in different versions they do not use the specification version as artifact version but incorporate the spec version in the artifact id. E.g. for Hibernate, the API JAR has the following coordinates:

2.0 - org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.1.Final
2.1 - org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.0.Final

Note, that these two do not represent a single artifact in different versions but two completely separate artifacts. Hence, dependency management systems will not be able to apply version conflict resolution to those and users are very likely to accidentally get both JARs into their classpath and then spend a lot of time debugging ClassNotFoundExceptions for their JPA 2.1 provider that might see the 2.0 JAR first.

Long story short, this is way more tedious than it needs to be. Releasing a canonical API JAR would solve these issues.

P.S.: No, a 1.8 MB JavaEE 7 API JAR is probably not what you want to pull into an application or library that depends on JPA only.

Generated at Mon Aug 31 22:59:44 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.