[hibernate-dev] JPA API jar artifacts

[Steve Ebersole]

I don't ever foresee that happening.  I don't know that it is 
"guaranteed" anywhere though.

On 08/27/2013 10:29 AM, Gunnar Morling wrote:
> Sounds reasonable to me.
>
> One question only: It is guaranteed that the JPA spec itself never 
> will do a micro update, right? I.e. the spec would never be updated 
> from say 2.2 to 2.2.1 (but to 2.3 in this case)?
>
>
> 2013/8/27 Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>>
>
>     I am contemplating duplicating[1] our existing JPA API jars to use a
>     better GAV naming scheme, specifically the GAV naming scheme we
>     plan on
>     adopting for any new JPA specs.  We have used completely different
>     naming scheme for 1.0 then we did for 2.0 and 2.1.  And even for
>     2.0 and
>     2.1 we used the JPA version in the artifactId rather than the version
>     portion of GAV.
>
>     The new scheme being proposed would be to use the groupId we have been
>     using for 2.0/2.1 ("org.hibernate.javax.persistence").  We would
>     use the
>     artifactId we have been using for 2.0/2.1, but without the 2.0/2.1
>     portion.  Currently, for example, we have "hibernate-jpa-2.1-api"
>     as the
>     artifactId; this would become just "hibernate-jpa-api".  We'd then
>     move
>     the JPA version as *part of* the GAV version.  Essentially the GAV
>     version would be broken into buckets with JPA version taking up the
>     first 2 positions, a "bugfix" position, and then a qualifier.  Given
>     1.0, 2.0 and 2.1 that would give us:
>     1) org.hibernate.javax.persistence:hibernate-jpa-api:1.0.0.Final.jar
>     2) org.hibernate.javax.persistence:hibernate-jpa-api:2.0.0.Final.jar
>     3) org.hibernate.javax.persistence:hibernate-jpa-api:2.1.0.Final.jar
>
>     I would only duplicate the last of each of 1.0, 2.0 and 2.1 into
>     the new
>     naming.
>
>     Moving forward, the only thing that "changes" would be qualifiers
>     if/as
>     we start working on new spec versions and possibly "bugfix"
>     portion (the
>     last '0') if we encounter problems in the jpa api jars after the fact
>     (normal bugfix semantics).  We are discussing standardizing on this
>     across the JBoss community and specifically discussing how to
>     handle the
>     qualifiers for ongoing work.  One option would be a new qualifier
>     "Draft".  It fits reasonably well in the existing (OSGi defined) alpha
>     sorting of qualifiers aside from the Draft->Final jump (what about
>     "Proposed Final Drafts"?). Personally I do not like the direct tie to
>     specific spec Drafts; personally I know sometimes I publish spec jars
>     that do not cleanly map to a Draft.  I personally prefer using
>     Beta for
>     Drafts, CR for Proposed Final Drafts  and Final for, well, Final
>     Drafts.  We'll have to see how that works itself out though.
>
>     Anyway, any issues/concerns with duplicating these historical
>     artifacts?
>
>     [1] I am thinking of duplicating rather than "relocating" since I
>     am not
>     sure how well tools handle relocated artifacts in general.  In fact I
>     think tools (Maven itself included) simply fail to resolve the
>     relocated
>     artifact.
>
>
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>