Re: [hibernate-dev] JPA API jar artifacts

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(a)hibernate.org <mailto:steve@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev