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.