jpa-spec
  1. jpa-spec
  2. JPA_SPEC-60

Upload official/standard JPA 2.1 API jar to Maven Central

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.2
    • Labels:
      None

      Description

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

        Activity

        Hide
        Lukas Jungmann added a comment -

        When I raised this question in the past I got an answer that all providers are expected to provide their own implementation of the API and since majority of providers are already doing it, as Neil mentioned, I felt, maybe wrongly, push against creating standalone vendor neutral api jar. Another thing is that I've never got an answer to who owns 'javax.persistence' groupid in maven central so the artifact would follow the naming convention as I don't have enough permissions to just deploy the jar there (...and I'm not talking about possible legal/licensing issues if I'd just find some way around - IANAL).
        It is also unlikely that it will change for already released 2.1.

        For 2.2 this absolutely has to change - what I want to have is JDK9 ready 'java.persistence' module defined with no additional dependencies for other to use; for example current jpa api jar provided by eclipselink contains few osgi classes which are not useful for others...

        Show
        Lukas Jungmann added a comment - When I raised this question in the past I got an answer that all providers are expected to provide their own implementation of the API and since majority of providers are already doing it, as Neil mentioned, I felt, maybe wrongly, push against creating standalone vendor neutral api jar. Another thing is that I've never got an answer to who owns 'javax.persistence' groupid in maven central so the artifact would follow the naming convention as I don't have enough permissions to just deploy the jar there (...and I'm not talking about possible legal/licensing issues if I'd just find some way around - IANAL). It is also unlikely that it will change for already released 2.1. For 2.2 this absolutely has to change - what I want to have is JDK9 ready 'java.persistence' module defined with no additional dependencies for other to use; for example current jpa api jar provided by eclipselink contains few osgi classes which are not useful for others...
        Hide
        neilstockton added a comment -

        Maybe all major JPA 2.1 vendors (EclipseLink, Hibernate, DataNucleus) already have done that (which they have since their implementations cannot be used without such a jar) but that doesn't solve the issue. There should be an official standard jar

        Show
        neilstockton added a comment - Maybe all major JPA 2.1 vendors (EclipseLink, Hibernate, DataNucleus) already have done that (which they have since their implementations cannot be used without such a jar) but that doesn't solve the issue. There should be an official standard jar
        Hide
        bkahlerventer added a comment -

        Maybe someone should implement this independently since Oracle appear to have abandoned J2EE, irrespective their public statements

        Show
        bkahlerventer added a comment - Maybe someone should implement this independently since Oracle appear to have abandoned J2EE, irrespective their public statements
        Hide
        mkarg added a comment -

        It would be good if there would at least any sign of life from the specification maintainers... Hello, Lukas, are you at least reading these comments...?

        Show
        mkarg added a comment - It would be good if there would at least any sign of life from the specification maintainers... Hello, Lukas, are you at least reading these comments...?
        Hide
        marcelstoer added a comment -

        If the maintainers have no intention of fixing this they should at least close it with 'won't fix' - and ideally give an explanation why such an obvious "feature" isn't implemented.

        Show
        marcelstoer added a comment - If the maintainers have no intention of fixing this they should at least close it with 'won't fix' - and ideally give an explanation why such an obvious "feature" isn't implemented.

          People

          • Assignee:
            Lukas Jungmann
            Reporter:
            Matthew Adams
          • Votes:
            36 Vote for this issue
            Watchers:
            18 Start watching this issue

            Dates

            • Due:
              Created:
              Updated: