On 04/05/2016 09:20, Emmanuel Bernard wrote:
:
JPA uses the service loader pattern to find the list of implementations.
But what Gunnar is describing is a concern of the API module itself.
For reasons related to history, license, copyright openness concerns and
code maintenance, there are several alternative incarnations of JSR APIs
floating around. They are all sig compliant as per the TCK but they have
different Maven GAVs
For JPA at the very least, there is the Oracle and Red Hat version. I'm
pretty sure Apache has its own too. So if the third party module Gunnar
mentions does use the hibernate version (which its own name), there is
no way for the third party module user to override this decision and use
the Oracle one.
I don't know how/when Java EE will embrace modules but I would expect
that module names will be chosen and that the module name, exports, etc.
will become part of the TCK signature test.
In the case of JPA then it might be "module java.persistence" where
compliant implementations will have a declaration like this:
module java.persistence {
exports javax.persistence;
exports javax.persistence.criteria;
exports javax.persistence.metamodel;
exports javax.persistence.spi
uses javax.persistence.spi.PersistenceProvider;
:
}
When you have an explicit module then it doesn't matter how the artifact
is named, the group/artifact/version in Maven isn't relevant to the
module system either.
I realize that we are in somewhat of a void at the moment in that there
aren't Java EE modules yet but cases like this, where they are several
different copies of the API classes, then maybe the folks involved could
come together with the spec lead for the API and agree the module name.
-Alan
