[hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

[Sanne Grinovero]

I'm reviewing how we expect people to use the Hibernate OGM modules on WildFly.

Scott mentioned that the JPA subsystem of WildFly automatically adds
the "org.hibernate.ogm" module when the
org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
set.

See also :
  - https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPAReferenceGuide-Determinethepersistenceprovidermodule

OGM's reference documentation recommends to add the modules depending
on which backend is being used, i.e. for CouchDB:

  org.hibernate.ogm services, org.hibernate.ogm.couchdb services

See the difference? We expect people to explicitly import he couchdb module too.
We essentially expect people to use a different API - i.e. a different
classpath - depending on the storage.. that's unusual.
The traditional answer is that you should have one API, but our case
is a bit more complex so let's see the options.

I'd like to get rid of the need specify modules. I see several paths,
some less compelling:

 A- consider the "couchdb" module a non-essential, power users only
API which you can only unlock by manually configuring modules.
   pros: it's done :)
   cons: would we agree that OGM is still compelling even without
those "options" for a majority of basic users?

 B- have WildFly inject all these modules on the user's classpath
  pros: consistency, no magic, everyone gets the same.
  cons: Requires updates in WildFly to support new datastores. Larger
classpath? More conflict potentials? More stuff to "support" ?

 C/1- have WildFly "guess" the right dependency set by looking at
additional properties.
   pros: exposes the minimum but not less
   cons: requires such logic to be defined in JipiJapa, needs long
term stability, needs to deal with multiple (different) PU
configurations.

 C/2- have WildFly invoke some helper of ours which defines the
modulesets we want
    pros: we can control and evolve this as we realise which mistakes
we're making :)
    cons: more complex to define this contract?


My vote goes to B, at least for the short term. C/2 is my favourite in
the longer term, or at least a B which allows us to define new
datastores without needing changes in WildFly.

Orthogonal to this, but to keep in mind: WildFly also injects the
"main" slot exclusively. We'll need a way to pick a specific version,
or at least allow overrides like we do with Search.

Thanks,
Sanne