Bill Shannon wrote:
> 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.
>
No, I don't get this point. IMO, a programmer should be able to compile
a portable JPA application without depending on any JPA implementation.
While running (or testing) the program, the programmer can choose an
implementation. The implementation comes with their definition of API
classes in addition to the implementation classes and their
dependencies. This applies to many other APIs, not just JPA. Maven
provides some features [1] for such a development model.
>> 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.
>
Maven experts can suggest better alternatives. This is what I can think of:
the pom file of the artifact should describe the artifact. For maven 2
style repositories, I expect maven-metadata.xml to describe information
common to all versions of an artifact. The default web page for our
repository,
http://download.java.net/maven/1, should describe the
repository, its purpose, its layout, and facts that applies to all the
artifacts in the repository.
>> 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?
That holds good for people who implement JPA, not for users who use JPA.
It is natural for a JPA user to depend on version 1.0 of
persistence-api, as the last known spec release is 1.0. May be you don't
consider this as an intended use case for persistence-api.
>
>> 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.
>
groupId is described in more than one place, but I find [2] useful. The
reason I said groupId for persistence-api is not correct is because, it
is Sun or GlassFish project's version of the APIs. Why should it be
javax.persistence?
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.
Thanks,
Sahoo
[1]
http://docs.codehaus.org/pages/viewpage.action?pageId=26408
[2]
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
[3]
http://www.nabble.com/Request-For-Enhancement%3A-Provision-of-MVN2-compatible-J2EE-artifact-tf2281419.html#a6337556