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

[Scott Marlow]

On 04/18/2016 11:32 AM, Sanne Grinovero wrote:
> 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.

If the slot is not "main", the application will use 
"jboss.as.jpa.providerModule" to specify the corrected module name.  If 
users need a "jboss.as.jpa.providerModuleSlot" option, that could be 
added.

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

Is there going to be one static OGM module for all targeted backends? 
Will the one static OGM module have its own ORM jars or depend on the 
ORM jars that WildFly packages?

 From our previous discussion, there are some OGM dependencies expected 
to leak into the application as well (perhaps via a Jipijapa extension, 
if we need a OGM integration layer in WildFly).

>
> 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
>>
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>