Issue Details (XML | Word | Printable)

Key: JPA_SPEC-60
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Matthew Adams
Votes: 16
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
jpa-spec

Upload official/standard JPA 2.1 API jar to Maven Central

Created: 13/Jun/13 02:27 PM   Updated: 07/Feb/14 10:11 AM  Due: 22/May/13
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags: maven repositories osgi
Participants: datanucleus, Matthew Adams, neilstockton and Oliver Gierke


 Description  « Hide

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)!



Matthew Adams added a comment - 13/Jun/13 02:28 PM

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


datanucleus added a comment - 13/Jun/13 02:54 PM

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) ...


Matthew Adams added a comment - 13/Jun/13 05:56 PM

http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C7.0%7Cjar

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


neilstockton added a comment - 14/Nov/13 04:32 PM

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.


Oliver Gierke added a comment - 07/Feb/14 10:10 AM - edited

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.