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

[Sanne Grinovero]

On 30 Mar 2016 21:11, "Scott Marlow" <smarlow at redhat.com> wrote:
>
>
>
> On 03/30/2016 12:15 PM, Sanne Grinovero 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
>>
>
> Which classloader needs access to CouchDB?  Will the application code
contain references to CouchDB because OGM is used by the application? Or
will the OGM (org.hibernate.ogm) module contain references to CouchDB?

Both.
The underlying datastore is not fully abstracted.

>
>
>> 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
>>