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

On 03/30/2016 12:15 PM, Sanne Grinovero wrote: > > I'm reviewing how we expect people to use the Hibernate OGM modules on

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

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

> See the difference? We expect people to explicitly import he couchdb

> 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >