11:15 a.m.
So recently, Hibernate Search has been added as a dependency of Wildfly.
I think for two reasons:
- Infinispan when using <indexing/> requires it
- CapeDwarf is a customer of Infinispan, its indexing and Hibernate
Search
I am a bit concerned about that move because Hibernate Search (depending
on the options you choose) can bring a significant dependency graph and
I don't want Wildfly to suffer from that.
As part of Hibernate Search, we do work and offer a Wildfly module to
ease the integration but it seems the work as been duplicated.
So my question to all of you guys is the following. Isn't it enough to
let Hibernate Search keep up with the module definition and let use add
the module when they need either Hibernate Search, Infinispan indexing
or CapeDwarf?
Emmanuel
11:26 a.m.
This was mostly discussed as part of added bloat debate:
http://lists.jboss.org/pipermail/wildfly-dev/2013-November/001125.html
I personally am not a fan!
On Mon, Dec 16, 2013 at 5:15 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
So recently, Hibernate Search has been added as a dependency of
Wildfly.
I think for two reasons:
- Infinispan when using <indexing/> requires it
- CapeDwarf is a customer of Infinispan, its indexing and Hibernate
Search
I am a bit concerned about that move because Hibernate Search (depending
on the options you choose) can bring a significant dependency graph and
I don't want Wildfly to suffer from that.
As part of Hibernate Search, we do work and offer a Wildfly module to
ease the integration but it seems the work as been duplicated.
So my question to all of you guys is the following. Isn't it enough to
let Hibernate Search keep up with the module definition and let use add
the module when they need either Hibernate Search, Infinispan indexing
or CapeDwarf?
Emmanuel
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:46 a.m.
On 12/16/2013 11:26 AM, Tomaž Cerar wrote:
This was mostly discussed as part of added bloat debate:
There is more to it then adding additional jars. We also need more than
zero unit tests and possibly more time in the schedule (WF 8/9).
http://lists.jboss.org/pipermail/wildfly-dev/2013-November/001125.html
I personally am not a fan!
On Mon, Dec 16, 2013 at 5:15 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org <mailto:emmanuel@hibernate.org>> wrote:
So recently, Hibernate Search has been added as a dependency of Wildfly.
I think for two reasons:
- Infinispan when using <indexing/> requires it
- CapeDwarf is a customer of Infinispan, its indexing and Hibernate
Search
I am a bit concerned about that move because Hibernate Search (depending
on the options you choose) can bring a significant dependency graph and
I don't want Wildfly to suffer from that.
As part of Hibernate Search, we do work and offer a Wildfly module to
ease the integration but it seems the work as been duplicated.
So my question to all of you guys is the following. Isn't it enough to
let Hibernate Search keep up with the module definition and let use add
the module when they need either Hibernate Search, Infinispan indexing
or CapeDwarf?
Emmanuel
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:12 p.m.
Yes I agree that we want to remove it from at least our primary distro. The solution
I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
was that we only pull in hibernate search to test <indexing/> but not ship it by
default.
On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
So recently, Hibernate Search has been added as a dependency of
Wildfly.
I think for two reasons:
- Infinispan when using <indexing/> requires it
- CapeDwarf is a customer of Infinispan, its indexing and Hibernate
Search
I am a bit concerned about that move because Hibernate Search (depending
on the options you choose) can bring a significant dependency graph and
I don't want Wildfly to suffer from that.
As part of Hibernate Search, we do work and offer a Wildfly module to
ease the integration but it seems the work as been duplicated.
So my question to all of you guys is the following. Isn't it enough to
let Hibernate Search keep up with the module definition and let use add
the module when they need either Hibernate Search, Infinispan indexing
or CapeDwarf?
Emmanuel
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
12:14 p.m.
The reason I merged the relevant PR BTW is just to help get CR out faster. I figured we
can fix it before Final.
On Dec 16, 2013, at 11:12 AM, Jason Greene <jason.greene(a)redhat.com> wrote:
Yes I agree that we want to remove it from at least our primary
distro. The solution
I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
was that we only pull in hibernate search to test <indexing/> but not ship it by
default.
On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> So recently, Hibernate Search has been added as a dependency of Wildfly.
> I think for two reasons:
>
> - Infinispan when using <indexing/> requires it
> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
> Search
>
> I am a bit concerned about that move because Hibernate Search (depending
> on the options you choose) can bring a significant dependency graph and
> I don't want Wildfly to suffer from that.
>
> As part of Hibernate Search, we do work and offer a Wildfly module to
> ease the integration but it seems the work as been duplicated.
>
> So my question to all of you guys is the following. Isn't it enough to
> let Hibernate Search keep up with the module definition and let use add
> the module when they need either Hibernate Search, Infinispan indexing
> or CapeDwarf?
>
> Emmanuel
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
12:30 p.m.
I remember that one and I must have read Brian's mail too fast as I did
not know we were going in that direction.
Note that another problem is that Hibernate Search had dependencies on
Hibernate ORM and Infinispan (optional but at the core of the feature
set).
Infinispan has dependencies on Hibernate Search (though optional).
Wildfly has dependencies on JPA and Hibernate ORM.
So adding Hibernate Search in the distro does remove a degree of
freedom.
Emmanuel
On Mon 2013-12-16 17:26, Tomaž Cerar wrote:
This was mostly discussed as part of added bloat debate:
http://lists.jboss.org/pipermail/wildfly-dev/2013-November/001125.html
I personally am not a fan!
On Mon, Dec 16, 2013 at 5:15 PM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
> So recently, Hibernate Search has been added as a dependency of Wildfly.
> I think for two reasons:
>
> - Infinispan when using <indexing/> requires it
> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
> Search
>
> I am a bit concerned about that move because Hibernate Search (depending
> on the options you choose) can bring a significant dependency graph and
> I don't want Wildfly to suffer from that.
>
> As part of Hibernate Search, we do work and offer a Wildfly module to
> ease the integration but it seems the work as been duplicated.
>
> So my question to all of you guys is the following. Isn't it enough to
> let Hibernate Search keep up with the module definition and let use add
> the module when they need either Hibernate Search, Infinispan indexing
> or CapeDwarf?
>
> Emmanuel
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
2:01 p.m.
Just to say, the bloat is to the distribution size only, not to the
actual runtime. The infinispan-query module (and its dependencies,
including hibernate-search) is *not* imported by the default
configuration. To use <indexing/> for an infinispan cache, you must
configure the cache container to load query module via:
<cache-container ... module="org.infinispan.query"/>
Only then are these modules loaded.
It's too bad your response never went out. Only 2 people responded to
my original thread with an opinion - both of which advocated for adding
the dependencies...
On Mon, 2013-12-16 at 11:12 -0600, Jason Greene wrote:
Yes I agree that we want to remove it from at least our primary
distro. The solution
I would have preferred, but never got sent to the ML (was in my drafts folder - oops)
was that we only pull in hibernate search to test <indexing/> but not ship it by
default.
On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> So recently, Hibernate Search has been added as a dependency of Wildfly.
> I think for two reasons:
>
> - Infinispan when using <indexing/> requires it
> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
> Search
>
> I am a bit concerned about that move because Hibernate Search (depending
> on the options you choose) can bring a significant dependency graph and
> I don't want Wildfly to suffer from that.
>
> As part of Hibernate Search, we do work and offer a Wildfly module to
> ease the integration but it seems the work as been duplicated.
>
> So my question to all of you guys is the following. Isn't it enough to
> let Hibernate Search keep up with the module definition and let use add
> the module when they need either Hibernate Search, Infinispan indexing
> or CapeDwarf?
>
> Emmanuel
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
2:38 p.m.
Yeah it’s my fault, and when your PR came in, I couldn’t reject it simply because I
dropped the ball.
The space usage does look minimal, we are looking at a 129MB zip, which is actually
smaller than Beta1 but fatter than Alpha4. Does this include all of the deps that someone
who wants to use hibernate search needs?
On Dec 16, 2013, at 1:01 PM, Paul Ferraro <paul.ferraro(a)redhat.com> wrote:
Just to say, the bloat is to the distribution size only, not to the
actual runtime. The infinispan-query module (and its dependencies,
including hibernate-search) is *not* imported by the default
configuration. To use <indexing/> for an infinispan cache, you must
configure the cache container to load query module via:
<cache-container ... module="org.infinispan.query"/>
Only then are these modules loaded.
It's too bad your response never went out. Only 2 people responded to
my original thread with an opinion - both of which advocated for adding
the dependencies...
On Mon, 2013-12-16 at 11:12 -0600, Jason Greene wrote:
> Yes I agree that we want to remove it from at least our primary distro. The solution
> I would have preferred, but never got sent to the ML (was in my drafts folder -
oops)
> was that we only pull in hibernate search to test <indexing/> but not ship it
by default.
>
> On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>
>> So recently, Hibernate Search has been added as a dependency of Wildfly.
>> I think for two reasons:
>>
>> - Infinispan when using <indexing/> requires it
>> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>> Search
>>
>> I am a bit concerned about that move because Hibernate Search (depending
>> on the options you choose) can bring a significant dependency graph and
>> I don't want Wildfly to suffer from that.
>>
>> As part of Hibernate Search, we do work and offer a Wildfly module to
>> ease the integration but it seems the work as been duplicated.
>>
>> So my question to all of you guys is the following. Isn't it enough to
>> let Hibernate Search keep up with the module definition and let use add
>> the module when they need either Hibernate Search, Infinispan indexing
>> or CapeDwarf?
>>
>> Emmanuel
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3:32 p.m.
The space usage does look minimal, we are looking at a 129MB zip,
which is actually smaller than Beta1 but fatter than Alpha4. Does this include all of the
deps that someone who wants to use hibernate search needs?
I can speak for CapeDwarf -- yes, current config / deps / ... work perfectly for us.
And, imo, we're the most complex user of these things (or at least I like to image
that :-)).
We use the whole stack extensively: Query, Hibernate Search, Lucene, Infinispan-Lucene,
JGroups for index updates, etc
-Ales
8:49 a.m.
On 16 December 2013 19:38, Jason Greene <jason.greene(a)redhat.com> wrote:
Yeah it’s my fault, and when your PR came in, I couldn’t reject it
simply because I dropped the ball.
The space usage does look minimal, we are looking at a 129MB zip, which is actually
smaller than Beta1 but fatter than Alpha4. Does this include all of the deps that someone
who wants to use hibernate search needs?
Actually no, it's missing one little jar which makes the integration
with Hibernate ORM possible; in our distribution that's usually living
in a separate module. Since we have all the dependencies already, I'd
rather add the small jar which would provide high value to
Hibernate/JPA users.
Note that the version needs to be adjusted too: the version currently
included in WildFly is not compatible with the Hibernate ORM version
in WildFly: we should use at least 4.5.0.Alpha3, which is also
compatible with Infinispan (Query).
I could send pull requests to get the module in correct shape, but
only if it's going to stay? I don't want Hibernate Search users to get
confused on where the modules are to be found.
Sanne
On Dec 16, 2013, at 1:01 PM, Paul Ferraro <paul.ferraro(a)redhat.com> wrote:
> Just to say, the bloat is to the distribution size only, not to the
> actual runtime. The infinispan-query module (and its dependencies,
> including hibernate-search) is *not* imported by the default
> configuration. To use <indexing/> for an infinispan cache, you must
> configure the cache container to load query module via:
> <cache-container ... module="org.infinispan.query"/>
> Only then are these modules loaded.
>
> It's too bad your response never went out. Only 2 people responded to
> my original thread with an opinion - both of which advocated for adding
> the dependencies...
>
> On Mon, 2013-12-16 at 11:12 -0600, Jason Greene wrote:
>> Yes I agree that we want to remove it from at least our primary distro. The
solution
>> I would have preferred, but never got sent to the ML (was in my drafts folder -
oops)
>> was that we only pull in hibernate search to test <indexing/> but not ship
it by default.
>>
>> On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>>
>>> So recently, Hibernate Search has been added as a dependency of Wildfly.
>>> I think for two reasons:
>>>
>>> - Infinispan when using <indexing/> requires it
>>> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>>> Search
>>>
>>> I am a bit concerned about that move because Hibernate Search (depending
>>> on the options you choose) can bring a significant dependency graph and
>>> I don't want Wildfly to suffer from that.
>>>
>>> As part of Hibernate Search, we do work and offer a Wildfly module to
>>> ease the integration but it seems the work as been duplicated.
>>>
>>> So my question to all of you guys is the following. Isn't it enough to
>>> let Hibernate Search keep up with the module definition and let use add
>>> the module when they need either Hibernate Search, Infinispan indexing
>>> or CapeDwarf?
>>>
>>> Emmanuel
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
9:51 a.m.
On 12/17/2013 08:49 AM, Sanne Grinovero wrote:
On 16 December 2013 19:38, Jason Greene
<jason.greene(a)redhat.com> wrote:
> Yeah it’s my fault, and when your PR came in, I couldn’t reject it simply because I
dropped the ball.
>
> The space usage does look minimal, we are looking at a 129MB zip, which is actually
smaller than Beta1 but fatter than Alpha4. Does this include all of the deps that someone
who wants to use hibernate search needs?
Actually no, it's missing one little jar which makes the integration
with Hibernate ORM possible; in our distribution that's usually living
in a separate module. Since we have all the dependencies already, I'd
rather add the small jar which would provide high value to
Hibernate/JPA users.
Note that the version needs to be adjusted too: the version currently
included in WildFly is not compatible with the Hibernate ORM version
in WildFly: we should use at least 4.5.0.Alpha3, which is also
compatible with Infinispan (Query).
I could send pull requests to get the module in correct shape, but
only if it's going to stay? I don't want Hibernate Search users to get
confused on where the modules are to be found.
Sanne,
Do you want Hibernate Search to stay in WildFly? If yes, do you also
want Hibernate Search to be in EAP.nextMajorVersion?
Scott
Sanne
>
> On Dec 16, 2013, at 1:01 PM, Paul Ferraro <paul.ferraro(a)redhat.com> wrote:
>
>> Just to say, the bloat is to the distribution size only, not to the
>> actual runtime. The infinispan-query module (and its dependencies,
>> including hibernate-search) is *not* imported by the default
>> configuration. To use <indexing/> for an infinispan cache, you must
>> configure the cache container to load query module via:
>> <cache-container ... module="org.infinispan.query"/>
>> Only then are these modules loaded.
>>
>> It's too bad your response never went out. Only 2 people responded to
>> my original thread with an opinion - both of which advocated for adding
>> the dependencies...
>>
>> On Mon, 2013-12-16 at 11:12 -0600, Jason Greene wrote:
>>> Yes I agree that we want to remove it from at least our primary distro. The
solution
>>> I would have preferred, but never got sent to the ML (was in my drafts folder
- oops)
>>> was that we only pull in hibernate search to test <indexing/> but not
ship it by default.
>>>
>>> On Dec 16, 2013, at 10:15 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>>>
>>>> So recently, Hibernate Search has been added as a dependency of Wildfly.
>>>> I think for two reasons:
>>>>
>>>> - Infinispan when using <indexing/> requires it
>>>> - CapeDwarf is a customer of Infinispan, its indexing and Hibernate
>>>> Search
>>>>
>>>> I am a bit concerned about that move because Hibernate Search (depending
>>>> on the options you choose) can bring a significant dependency graph and
>>>> I don't want Wildfly to suffer from that.
>>>>
>>>> As part of Hibernate Search, we do work and offer a Wildfly module to
>>>> ease the integration but it seems the work as been duplicated.
>>>>
>>>> So my question to all of you guys is the following. Isn't it enough
to
>>>> let Hibernate Search keep up with the module definition and let use add
>>>> the module when they need either Hibernate Search, Infinispan indexing
>>>> or CapeDwarf?
>>>>
>>>> Emmanuel
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3780
days inactive
3781
days old
10 comments
7 participants
participants (7)
-
Ales Justin -
Emmanuel Bernard -
Jason Greene -
Paul Ferraro -
Sanne Grinovero -
Scott Marlow -
Tomaž Cerar