[hibernate-dev] JPA API jar artifacts

Steve Ebersole steve at hibernate.org
Tue Aug 27 10:57:12 EDT 2013


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.





More information about the hibernate-dev mailing list