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