Sahoo wrote:
> 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.
To be portable, these standalone programs need to package the
implementation of these other APIs along with the application.
The application can specify a dependency on whatever jar files
the implementation provides.
> 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.
Probably not. If you can figure out where we should document it,
we can do that.
> 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.
What sort of confusion? Wouldn't you naturally choose the newest version
within the release family that you're targeting?
> 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?
Sorry, I don't know how groupID is used.