On 28 March 2017 at 17:28, Steve Ebersole <steve(a)hibernate.org> wrote:
On Tue, Mar 28, 2017 at 11:12 AM Sanne Grinovero <sanne(a)hibernate.org>
> 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
> 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".
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.