Re: [hibernate-dev] What's the identity of Hibernate OGM's "public API" module?
On 30 March 2016 at 18:35, Davide D'Alto <davide(a)hibernate.org> wrote:
I don't think I like the idea of adding unnecessary dependencies
on the user
classpath.
I don't like it either, but specifically why not?
It would be less "magic" which is usually a good thing in these complex
systems.
If I understand correctly, you would add a lot of dependencies to
avoid
adding:
org.hibernate.ogm.couchdb service
I think this is something that a "Basic user" can handle.
I don't think it's worth to work for another solution that we don't plan to
use in the long term.
I'm not sure how to interpret you: are you voting against option B, or
voting against doing any change?
It's not about having the user to have to type just "org.hibernate.ogm
services", rather than "org.hibernate.ogm services,
org.hibernate.ogm.couchdb services" :
it's about the user not needing to add any Manifest, any XML nor
having to read 5 pages of reference documentation about details of
modules configuration in WildFly.
So my proposals are about how to close the final step, so we can remove it all.
My preference goes to C, the user already has to set
hibernate.ogm.datastore.provider, I think it would be nice to use the same
property to
know which module we need.
To clarify to others, for using CouchDB, the user already has to set the
property:
hibernate.ogm.datastore.provider = couchdb_experimental
There are constants for each available datastore:
ehcache, infinispan, mongodb, ...
Sure, some logic could read out properties, that's C1. The problem for
me is that if this logic is hardcoded in WildFly we're stuck with the
modules it supports and we can't add new dialects in new releases of
OGM.
To implement C/2 I suspect we'll need to expose some contract which
allows us to select it, and JipiJapa/OGM will have to invoke that.. so
at least the contract API needs to be stable in the long term.
Thanks,
Sanne