Sahoo wrote:
> 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.
Yes, in the same way you can compile a Java SE program without depending
on any Java SE implementation. Certainly the API jar file we make available
is suitable for that, as is the javaee.jar file we make available.
> 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.
We've only defined portable packaging at the Java platform level.
If you deploy on Java EE, you don't have to worry about the Java
Persistence implementation, it's always available. If you deploy
on Java SE, there is no Java Persistence implementation guaranteed
to be available. You either have to carry with your application to
ensure that you can deploy anywhere, or you have to do something
outside of your application package to configure it to use a particular
Java Persistence implementation.
>>> 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.
I'll defer to our Maven experts.
>>> 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.
If you saw version 1.0 of that jar file, and version 1.0.1 of that jar
file, wouldn't you choose 1.0.1?
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.
>>> 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?
It's the APIs defined by the reference implementation. Why shouldn't
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.
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?