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

[Sanne Grinovero]

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.

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.

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