[hibernate-dev] JPA API jar artifacts

[Steve Ebersole]

One option is a special qualifier.  2.2.1.Final (our bugfix) versus 
2.2.1.Maintence (spec maintenance).  Could still lead to "bad sorting", 
but does avoid collisions.

Also note that since 1.0 we have never needed a bugfix release.  For 
what its worth...


On Tue 27 Aug 2013 11:24:52 AM CDT, Gunnar Morling wrote:
> I see.
>
> The reason I'm asking is that there theoretically could be a collision
> between the version of such a maintenance release of the spec and a
> previous bug fix release of our spec API JAR which e.g. would then
> both have the version "2.2.1".
>
> Not sure whether one should be prepared for such a case or whether
> it's actually no issue in practice.
>
>
> 2013/8/27 Emmanuel Bernard <emmanuel at hibernate.org
> <mailto:emmanuel at hibernate.org>>
>
>     Technically the spec could go in what is called maintenance mode. In
>     which case the spec lead could use micro or some prefix like M1.
>     But we don't know if that will happen for JPA nor which one will be
>     chosen.
>
>     Emmanuel
>
>     On Tue 2013-08-27 10:55, Steve Ebersole wrote:
>     > 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>
>     > > <mailto: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>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>     > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     > >
>     > >
>     >
>     > _______________________________________________
>     > 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
>
>