javax.persistence:javax.persistence-api:2.2 should show up in maven central in few hours.
toggle quoted messageShow quoted text
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 specYes, JavaMail.
which would have similar direct compile time dependency on the
non-spec/non-javax artifact in its official API jar?
You've all read my writeup that describes the different jar files , 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.