Just thought I'd weigh in with my thoughts... I've almost responded a
couple times during this thread, but held off until now.
On 6/26/07, Bill Shannon <bill.shannon_at_sun.com> wrote:
> If you think there's some better naming scheme to distinguish the newer
> version from the older version without confusing people about whether
> or not it corresponds to version 1.0 of the spec, I'm open to it.
I'd suggest simply deciding how you will version the spec, and then
plan on adding an additional number to the end to notate build number
or whatever. So all builds named 1.0.x would match the api version 1.0
of the spec. If you anticipate using 3 numbers in the spec
name/version, then you'd use an artifact naming scheme of 1.0.0.x,
resulting in actual jars named jpa-1.0.0.3948.jar.
It is almost impossible to say "we never make mistakes, so v1.0 of our
jar always matches v1.0 of the api spec". Thus, you need to add
another field on the end and document the versioning strategy so
people can figure it which specific jar they need for themselves.
> > is Sun or GlassFish project's version of the APIs. Why should it be
> > javax.persistence?
>
> It's the APIs defined by the reference implementation. Why shouldn't
> it be "javax.persistence"?
If the api is produced by the JCP, then I see no reason for it to be
named anything other than javax.persistence. I don't see vendors
fighting between each other over who will produce the one true API
jar.
Having said that... previous releases of API jars were not available
in Maven repos due to the click-shrinkwrap on Sun.com and licensing
issues, and many of us turned to Geronimo's implementation of the API
jars. Assuming the licensing doesn't change, I think the javax.*
groupId is appropriate for JCP produced artifacts.
> > An artifact like persistence-api.jar could be made more granular. The
> > two functionalities that it offers should be separated. The signature
> > part should be made available as groupId javax.persistence, where as the
> > implementation one should be available with a groupId more specific to
> > GlassFish or Sun. The former one can even be made available in Maven's
> > central repository if the licensing policy allows it to be. This will
> > benefit Java users. I think this is what the original request [3] meant.
>
> Are you saying that we haven't satisfied the original request?
>
> Sure, we could make two versions of persistence-api.jar available.
> And in some sense that would be more "pure". It just doesn't seem
> important. I don't see what serious problem it solves that can't
> be solved by the jar files we currently make available.
>
> Are you arguing that we should do this for *all* the API jar files
> because "it's the right thing to do"? Or is there a real problem
> I'm not understanding that would justify doing this extra work?
I can't speak for Markus (the original RFE author) but as a fellow
Maven2 user, I know where he is coming from. I actually did some work
quite a while ago to produce API jars out of the Glassfish project for
the reasons he mentioned.
I also don't know much about the specific contents of the
persistence-api.jar at this moment in time, but I do generally agree
with the thought that producing 2 jars, one containing strictly the
API itself, and another containing Glassfish's implementation of the
API (which depends of course on the API jar) is the right way to do
things. The API itself would probably be published under
javax.persistence and the implementation would be published under the
corresponding Glassfish groupId, with a dependency (in the Maven2
pom.xml file) on the API artifact. Additionally (and ideally), the
Glassfish implementation would actually not bundle the API files in
the impl jars.
Wayne