Overriding requirements of 3rd party modules

[Emmanuel Bernard]

On Tue 2016-05-03 14:45, Alan Bateman wrote:
> On 03/05/2016 13:46, Gunnar Morling wrote:
> > Hi,
> > 
> > While looking into Jigsaw-enabling some existing code, I came across the
> > following use case for which I'm seeking advice on how to deal with.
> > 
> > Consider a 3rd party library that contains JPA entities. Application
> > developers will include that library into their app and work with its
> > entities as part of their model. The library author doesn't know which JPA
> > provider will be used (Hibernate, EclipseLink etc.), so the library should
> > work with any compatible provider.
> > 
> > Now the different providers all have their own JPA API Jar. Thus in the
> > module-info.java of the library, there'd be a "requires" clause to one of
> > the API Jars (e.g. "hibernate-jpa-2.1-api") for compiling and testing the
> > library.
> > 
> > But users of the lib might want to use *another* JPA provider and hence
> >   API Jar for their app. What's Jigsaw's approach for letting the user deal
> > with that? I.e. how could the user override the requirement of the lib in
> > order to work with the provider of their choice?
> > 
> > I vaguely remember a concept of "module aliases" in earlier drafts which
> > might have been used for that (for instance, all the different API Jars
> > could act as "jpa-2.1"), but I cannot seem to find that in the current docs
> > anymore.
> > 
> The early exploration phase did have some support for aliasing (`provides
> jpa` for example). This is not in the current design.
> 
> An alternative is to use services of course, say where there is one API
> module and a service provider interface to allow the implementation be
> plugged in. The current design (with `uses` and `provides`) leads itself
> very well to this type of loose coupling. We have many examples in Java SE
> and the JDK. Sorry I don't know JPA too well to know whether this applies or
> not but I do see a javax.persistence.spi package that looks like it
> supporting plugging in alterative implementations.

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.

Hope that clarifies.

emmanuel