[hibernate-dev] Fwd: [jdf-dev] JBoss Modules dependency vs pain POM dependency + exclusions

[Scott Marlow]

On 06/06/2013 05:26 PM, Sanne Grinovero wrote:
> Hibernate Search has many additional dependencies on top of just ORM..
> would the WildFly team be happy with that?
> I always assumed that would not be considered acceptable.

Its not every dependency that needs to be put into the Hibernate ORM 
static module, just the ones that the ORM service loader needs to see. 
Are the additional dependencies also loaded as ORM services?

I'm not against saying no to including Hibernate Search jars in 
application deployments.  That would be the easiest.

The best reason that I have heard for including Hibernate ORM jars with 
the application, is that they want to stay with that version of 
Hibernate while moving forward to a newer application server version 
that may be bundling a newer Hibernate version.  If found it problematic 
to support deployments having their own Hibernate ORM jars, when there 
are bidirectional 1-1 dependencies on the static Hibernate ORM module 
referencing code that we use with Hibernate ORM.

>
> Also with such a solution people won't have flexibility on the
> version; I know people don't have it with ORM either - unless they
> bring their own - but to make upgrades possible in existing projects
> it is extremely useful to be able to update one dependency at a time,
> which I suspect would not be possible anymore:
> upgrade ORM first, run the tests, upgrade Search, run the tests.
> Nailing down one version - by using the ORM provided by an application
> server - makes this harder, but nailing down both versions forces
> people to upgrade both at the same time: if there's an issue it will
> be much harder to figure out the area.

We could look again at some of the suggestions on 
http://jboss-as7-development.1055759.n5.nabble.com/Modularity-is-the-spawn-of-Lucifer-and-a-stinking-donkey-td5697958.html 
for changing how we do service loading in Hibernate.  I don't think any 
of the suggestions helped the last time we tried to improve service 
loading (modular classloading doesn't have inverse dependencies and we 
can't pass classloaders into the Hibernate ORM service loading code). 
But, maybe I'm wrong and we could make a change somewhere for improvement.

>
> Sanne
>
> On 6 June 2013 18:42, Scott Marlow <smarlow at redhat.com> wrote:
>> On 06/06/2013 11:49 AM, Emmanuel Bernard wrote:
>>> On Thu 2013-06-06 11:31, Scott Marlow wrote:
>>>>
>>>> If the static Hibernate Search module, depends on a static Hibernate
>>>> ORM module in WildFly 8, I think that is fine, but applications
>>>> wouldn't be able to include their own Hibernate Search jars (since
>>>> the static Hibernate ORM module only sees services in the static
>>>> Hibernate Search module).
>>>
>>> That's one deployment and the one I did first (see my other email).
>>>
>>>>
>>>> For WildFly 8, do we want to allow applications to bundle its own
>>>> version of Hibernate Search that could work with bundled Hibernate
>>>> ORM jars?
>>>
>>> It's a bit confusing to me this whole business but AFAIU but if we
>>> could, yes that would be good.
>>>
>>
>> To handle application deployments that contain their own Hibernate
>> Search jars, we would need to make an adjustment.  Instead of having the
>> Hibernate ORM module depend on the Hibernate Search module (this is what
>> we currently do in AS7 via 1-1 bidirectional dependencies), we would
>> need to include the Hibernate Search jars in the Hibernate ORM module.
>> This is specific to WildFly 8 (assuming my WF8 patch is merged in).
>>
>> If we don't put Hibernate Search into the ORM module, we will face the
>> same blocking issue that I saw very late on AS7, which is the JipiJapa
>> integration code module (used to be in AS7 codebase) depends on the
>> static Hibernate ORM module which conflicts with the Hibernate ORM jars
>> loaded by the application classloader.
>>
>> Also, keep in mind that In AS7, there was no JipiJapa project, so
>> applications couldn't easily include the JipiJapa integration classes
>> (point being that there were several blocking issues that prevented
>> Hibernate 4.x jars from being in the deployment).  Of course, Hibernate
>> 3 jars were different as there is no Hibernate 3 static module in AS8
>> (so applications could include Hibernate 3 jars).
>>
>> There were some other ways of dealing with service loading mentioned on
>> the "stinking donkey" thread [1] last year, but I'm not sure if any of
>> the alternatives would help application deployments to include Hibernate
>> ORM/Search/other jars.
>>
>> [1]
>> http://jboss-as7-development.1055759.n5.nabble.com/Modularity-is-the-spawn-of-Lucifer-and-a-stinking-donkey-td5697958.html
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev