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

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