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

[Davide D'Alto]

I don't think I like the idea of adding unnecessary dependencies on the
user classpath.
If I understand correctly, you would add a lot of dependencies to avoid
adding:

org.hibernate.ogm.couchdb service

I think this is something that a "Basic user" can handle.
I don't think it's worth to work for another solution that we don't plan to
use in the long term.

My preference goes to C, the user already has to set
hibernate.ogm.datastore.provider, I think it would be nice to use the same
property to
know which module we need.

To clarify to others, for using CouchDB, the user already has to set the
property:

hibernate.ogm.datastore.provider = couchdb_experimental

There are constants for each available datastore:

ehcache, infinispan, mongodb,  ...


On Wed, Mar 30, 2016 at 5:15 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>