Wayne Fay wrote:
> 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.
That's what I proposed as well.
Note also that there are times when we need to update the spec (e.g.,
to fix typos) without changing the jar file. The convention for that
is to add (e.g.) "Rev A" to the spec version number.
> 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.
There's times when you want the pieces separate, but I think in most cases
the convenience of bundling them together is much better. How to name and
version such a bundle in maven is something I suppose we could discuss.
Note also that the persistence-api.jar file doesn't include any
GlassFish-specific implementation code. It just includes the essential
implementation code required by the concrete classes in the API, e.g.,
the exception class implementations and the Persistence bootstrap class
implementation. All the real implementation (TopLink Essentials) is
elsewhere.