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

[Sanne Grinovero]

I think there was some confusion in this thread, probably it wasn't
clear that WildFly 10 already does inject automatically OGM, and that
ship sailed so we have to keep in mind what Jipijapa is going to do by
default:

The current state in WildFly 10's deployers is very simple: if it
"sees" that the persistence.xml is defining a Persistence Provider
named "org.hibernate.ogm.jpa.HibernateOgmPersistence", then it will
look for a module named "org.hibernate.ogm" and inject this to the
classpath. That does imply slot "main" is expected to be available.
This logic can be overriden, but it requires the user to specify - and
know about - additional configuration properties.

We can try deciding what we want WildFly 11+ to do better in the
future, but we need to decide at high priority what approach to use
for OGM 5.0.0.Final, given the WildFly-was-released restriction.

Now to reiterate the problem I mentioned in the first email of this
thread: having just the right version of "org.hibernate.ogm" isn't
good enough as one needs the specific dialect modules too.
I asked (teasing) if you all could see the specific dialect options as
power-user extensions, but it seems the consensus is that these are
not really optional.

So I guess I agree with Gunnar and Davide: [in current WildFly] one
will need to use the jboss-deployment-structure.xml or the Manifest to
make use of OGM, and we'll have to ignore the fact that when one of
these is missing the WildFly deployer will get mad as OGM:main can't
be found.

More inline:

On 31 March 2016 at 11:48, Gunnar Morling <gunnar at hibernate.org> wrote:
> So I think for the time being I'd be fine if WF didn't add anything
> implicitly at all for OGM.

Too late, hope that's clear now.

> The reason being, that OGM is not (yet) part of WF, the user needs to put in
> the modules from the ZIP themselves. So it seems acceptable to me to add the
> dependencies to the required modules by hand (matching the slot of the
> modules they unzipped).

Yes, acceptable for the time being, but for a future version of WF it
would be nice to not have users create (and learn about) yet another
configuration file.

> Should WF do it automatically, some logic along these lines would be needed:
>
> * If OGM is the persistence provider and there is only one set of OGM
> modules available, add all the OGM modules actually present (e.g. the user
> could have unzipped only core and one of the backends); Optionally, only add
> those backend(s) actually in use as per the configuration
> * If more than one set of OGM modules is available, require the user to
> explicitly specify the slot
>
> How about doing this once OGM actually is part of WF? Then one could default
> to the provided version, requiring the override only if the user wishes to
> use (and provides) another version.

+1 but to eventually allow WF to pick a specific OGM slot, we should
first release versioned modules.

I initially thought that we could provide an alias module "main ->
current release" to have the jipijapa integration work in certain
circumstances, but realising that the dialect-specific modules are
needed too, I guess this would be pointless.

So my plan is to simply switch our released modules to a specific
slot, then update the documentation accordingly. Not sure how far
jipijapa will try to stop me :) we might need additional JPA
properties too to override it.

Thanks,
Sanne



>
> --Gunnar
>
>
>