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

[Sanne Grinovero]

Hi Scott,

sorry for the delay, we finally discussed this over chat.

We decided to start producing Hibernate OGM modules which include a
Version identification in the slot name. For now we'll also include an
alias to resolve "main" to the new format, so WildFly won't break yet.

But for the future we think that it would be best to have WildFly not
depend on the "main" slot automatically, at least until WildFly
doesn't include a version of OGM.
If we eventually agree to include OGM superpowers within WildFly, then
that version will be named "main" and jipijapa could default to that.

Until that day comes, we'd prefer it if you could disable this
functionality of Jipijapa, or maybe expect a (required?) property to
have the user explicitly state which version should be used.

Thanks,
Sanne


On 21 April 2016 at 14:59, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> 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
>>
>