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

[Sanne Grinovero]

On 31 March 2016 at 10:09, Davide D'Alto <davide at hibernate.org> wrote:
>> Although I don't see a big issue in demanding to add a specific module
>> dependency. It's documented and I don't think I remember any user report
>> complaining about it. People also add dependencies to their Maven POM :)
>
> +1

Sure we can keep that requirement of having to explicitly list the dependencies;
what bothers me though, is that WildFly is going to add half of the
needed modules
automatically, AND hardcodes the slot.

That's really not aligned with what we have in our documentation.

So, should we rather ask Scott to remove that OGM support code from WildFly?

I'd rather have WildFly add all the modules, at least people can
forget about this.

Thanks,
Sanne


>
> On Thu, Mar 31, 2016 at 7:39 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> 2016-03-30 18:15 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> > 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.
>> >
>>
>> That has been an explicit choice; Different stores e.g. expose different
>> mapping strategies and configuration options. There are annotations and a
>> fluent API which live in the respective modules, allowing the user to
>> configure these specifics in a safe way. Instead of exposing the super set
>> of all these specifics from all stores in one common API, we pushed these
>> specifics to the backend modules (with some re-use within a type of store,
>> say document stores, where it made sense).
>>
>>
>> > 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?
>> >
>>
>> No, that's not really feasible. Users need to be able to access these
>> store
>> specifics.
>>
>>  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.
>> >
>>
>> Yes, C/2 would be nice to have.
>>
>> Although I don't see a big issue in demanding to add a specific module
>> dependency. It's documented and I don't think I remember any user report
>> complaining about it. People also add dependencies to their Maven POM :)
>>
>> Another question is how to deal with backends not part of the "official"
>> OGM package. Would users have to fall back to the explicit dependency for
>> those?
>>
>> 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.
>> >
>>
>> That's the beauty of manual configuration: People can select the slot they
>> want :) Right now I don't see a huge benefit in replacing one property in
>> the manifest with another property in persistence.xml.
>>
>> All in all I feel it might be a nice improvement, but I don't think its
>> impact is huge.
>>
>> Thanks,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>