[hibernate-dev] Javassist dependency conflict in the ORM modules for WildFly

[Sanne Grinovero]

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