[hibernate-dev] JPA API jar artifacts

[Emmanuel Bernard]

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>>
> >
> >     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
> >
> >
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev