[hibernate-dev] JPA API jar artifacts

[Gunnar Morling]

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>

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