Re: JPA 2.2 API on Maven Central

Guillermo González de Agüero

That's just great! Thanks a lot Lukas!


Guillermo González de Agüero

El lun., 21 de agosto de 2017 17:15, Lukas Jungmann <lukas.jungmann@...> escribió:
javax.persistence:javax.persistence-api:2.2 should show up in maven
central in few hours.


On 8/9/17 10:20 PM, Bill Shannon wrote:
> Lukas Jungmann wrote on 08/ 9/17 04:33 AM:
>> ... Is there any Java EE related spec
>> which would have similar direct compile time dependency on the
>> non-spec/non-javax artifact in its official API jar?
> Yes, JavaMail.
> You've all read my writeup that describes the different jar files [1], right?
> The API jar file was never intended to be something that could be reused
> by different implementations from different vendors.  I realize that often
> it is, but that wasn't its purpose.
> Every vendor was expected to create their own complete implementation,
> which would include the API class files as well.
> The API jar file was intended *only* to be used to compile against.
> To run an application, you need a complete implementation, which should
> come with the required API definitions.  Obviously the implementation
> jar file should have a Maven group ID appropriate to the vendor.  Only
> the API jar file has the "neutral" javax.* group ID.
> While our APIs often consist mainly of Java interfaces, they usually
> contain Exception classes, and sometimes contain "bootstrap" classes
> such as Persistence.  These classes might need to include vendor-specific
> code, e.g., to handle internationalization of messages, perform logging,
> integrate with an app server, or to reference other vendor-specific
> implementation classes.  There's nothing that restricts an implementation
> of a standard Java API from doing so, which is why the API class files
> might not actually be reusable between vendors.
> If you're creating your own implementation of an API such as JPA, you
> can fork the open source RI code to get the API classes, or you can
> write them yourself.  The TCK will ensure that the API classes are
> correct and compatible with the spec.  If you want your implementation
> of the API to depend on the API jar file instead of including your own
> implementation of the API classes, that might or might not work, depending
> on the actual implementation of the API classes.  And it might work in one
> release and break in the next.
> If you're writing an application that just needs to compile against the
> standard APIs, use the API jar file when compiling, and provide an
> appropriate implementation at runtime.
> [1]

Join to automatically receive all group messages.