> 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 <gun...@hibernate.org> wrote: > 2016-03-30 18:15 GMT+02:00 Sanne Grinovero <sa...@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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
