One thing to keep in mind is that the module system of Java 9 ("Jigsaw")
doesn't support a notion of optional module dependences.So if this is meant to remain an "optional feature" (i.e. Geo-specific libraries are not required at runtime when not using the spatial stuff), it should remain a separate artifact - this is, should we plan to make Hibernate ORM JARs Jigsaw modules at some point. --Gunnar 2016-06-28 15:22 GMT+02:00 Karel Maesen <ka...@geovise.com>: > It makes sense for some Dialects such as those for MySQL and MS SQL Server. > Less so for Postgresql and Oracle Spatial because here the spatial > capabilities need to be installed and configured separately (and even have > versioning separate from the main database engine). > > I would favour an approach, close to what Sanne is suggesting, where the > spatial capability (Incl. Types) is injected into the Dialect during > Dialect construction based on some explicit configuration. In that way the > relation between Dialect and the spatial capability mirrors the relation > between database engine and spatial capability (if any). > > Regards, > > Karel > > PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be > able to resume the exchange before July 20. > > On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <st...@hibernate.org> > wrote: > > > They have not been "merged" in the same way we merged > > hibernate-entitymanager into hibernate-core. So at the moment using > > hibernate-core e.g. does not require geolatte to be present. geolatte is > > only required if using hibernate-spatial (isolated transitive dep). > > > > Karel, what are your thoughts on this? I am not a fan of making geolatte > > optional/provided, but if we all deem that folding hibernate-spatial into > > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is > desirable > > then I will accept that > > > > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sa...@hibernate.org> > wrote: > > > > > Nice idea! > > > > > > since the modules were merged already, don't we already require > > > geolatte-geom ? > > > I guess some code might be intentionally designed to fail gracefully > > > about this library being there or not, but we'd need to make sure that > > > can be tested for it to be maintainable. > > > > > > My preference would be to have: > > > - All Dialects automatically provide the spatial extensions if the > > > needed dependencies are in place: we could automatically alias them > > > based on this? > > > - a good error message naming the missing dependencies explicitly > > > when someone attempts to use such a Spatial extensions, but the > > > feature was not enabled by our automatic logic. > > > - be able to test for these. > > > > > > In practice I believe this means we should still have it as an > > > independent source module, compile and test it as an independent > > > module, and only bundle within the ORM main jar as final distribution > > > step. > > > > > > If that's too much work, I'd rather make the geolatte-geom a mandatory > > > dependency than to have cryptic runtime failures. > > > > > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.v...@gmail.com> > wrote: > > > > Hi, > > > > > > > > Since hibenrate-spatial has been merged into Hibernate code base, > > > shouldn't > > > > we merge the Dialects as well. > > > > For instance, we have MySQL56InnoDBSpatialDialect which can simply be > > > > merged into a MySQL56InnoDBDialect. > > > > This way, MySQL57InnoDBDialect can take advantage of spatial queries > as > > > > well. > > > > > > > > The only drawback is that we need to add the geolatte-geom lib to > > > > hibernate-orm. > > > > > > > > Let me know what you think. > > > > > > > > Vlad > > > > _______________________________________________ > > > > hibernate-dev mailing list > > > > hibernate-dev@lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
