Overriding requirements of 3rd party modules

[Alan Bateman]

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