On 28 March 2017 at 17:28, Steve Ebersole <st...@hibernate.org> wrote: > > > On Tue, Mar 28, 2017 at 11:12 AM Sanne Grinovero <sa...@hibernate.org> > wrote: >> >> Hi Scott, >> >> no I don't think that's possible. There are many ways of bootstrapping >> Hibernate, and "using code" is also a valid option, which implies end >> users have the option to read configuration properties from custom >> sources or even hard-code configuration. >> >> Granted in practice they'll likely use Spring or other frameworks to >> boot it, but a list of such frameworks would necessarily be >> open-ended. >> >> Not least, I wouldn't want you to automatically add Hibernate ORM >> dependencies as it's very likely in most of these cases that the end >> user will want to use a different version of Hibernate ORM to match >> the requirements of the framework do jour, or otherwise include a >> custom version. >> >> The only "safe default" would be to inspect the bytecode of the >> deployment and see if both conditions are true: >> - any class refers to Hibernate (JPA) code / annotations >> - no Hibernate version is included > > > You mean strictly in terms of whether to inject Hibernate dependencies I > guess. Because this does not give Scott what he asked for. As I mentioned > to Scott on HipChat, the only possible "auto" choice I can see is whether > the app includes a persistence.xml, but even that can be inaccurate. > > So ultimately I think there should also be a deployment flag to be the > definitive answer to whether we should "inject Hibernate" because the user > "asked for it".
+1 Above I'm just trying to describe why any other alternative is not safe. Not least, any reasonable user will prefer a configuration line over some unclear, automagic strategy. I'd highly prefer consistency, especially when it comes to dependencies I'll have on classpath. Thanks, Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
