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

[Davide D'Alto]

> 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

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
>