dev@glassfish.java.net

Re: Implementation details in javax.persistence.persistence-api Maven jar???

From: Sahoo <Sahoo_at_Sun.COM>
Date: Mon, 25 Jun 2007 16:55:22 +0530

Bill Shannon wrote:
> Sahoo wrote:
>> Hi,
>>
>> As per the original intent documented here [1], the
>> persistence-api-${version}.jar should not be containing any method
>> implementation details, but the current ones [2] have them. Check the
>> Persistence.class that's part of the currently hosted
>> persistence-api-1.0.jar and persistence-api-1.0b.jar.
>>
>> So, the question is are we not stripping the implementation details?
>> Is this by choice or a bug? I think it's a bug.
>>
>> Thanks,
>> Sahoo
>>
>> [1]
>> http://weblogs.java.net/blog/ludo/archive/2007/01/java_ee_5_apis.html
>> [2] http://download.java.net/maven/1/javax.persistence/jars/
>
> I guess it depends on how you think these things are intended to be used.
>
> With things like the persistence APIs, it's feasible to get the API
> definitions from the maven repository and get a separate implementation
> from the maven repository (or elsewhere), combine them together, and have
> something useful. The APIs are designed to support pluggable
> implementations.
> That's *much* less true with javaee.jar as a whole.
>
> javaee.jar is just a convenient collection of all the Java EE APIs for
> people who just need to (e.g.) compile against the APIs without needing
> a Java EE runtime in the compilation environment. We haven't seen any
> demand for that compatibility for the individual Java EE specs.
>
> For the individual Java EE specs, people seem to want a complete
> implementation
> they can just use, or they want the API definitions in a form that allows
> them to build their own implementation. The separate API jar files
> satisfy the latter need.
>
> If there's demand for API definition files that are only good for
> compiling
> against, we could do that too.
>
>
Some of the individual APIs such as JPA, JDO, etc. are heavily used in
standalone programs. In order to ensure portability, those applications
should be able to specify dependency in a standard way and at a finer
level. So, we should cater to the needs of both the usages of the APIs.
Currently, while javaee.jar caters to the needs of Java EE users,
persistence-api.jar caters to the needs of implementers of the API. This
is kind of inconsistent and confusing. I don't know if this is
documented in public domain as well as it should be.
Having implementation details in API jar file makes it that much more
likely to have multiple versions of a jar for a given version of the
underlying specification release. Hence, the latest maven version number
of such a jar may not always match the corresponding version of the
spec. e.g., fixing issue #3229 [1] will require the version of
javax.persistence/persistence-api.jar to be changed. That will create
confusion among users while choosing the version number.
Even if the decision has been taken anticipating the kind of usages of
these jars, the choice of groupId is confusing. Is GlassFish or com.sun
not an appropriate groupId for the current persistence-api.jar?

Thanks,
Sahoo

[1] https://glassfish.dev.java.net/issues/show_bug.cgi?id=3229