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 <gun...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
