I dropped the ball on the package split for a couple of days, but would like to
get this completed now.
> It seems we are all ok except on the SearchFactory shuffling.
Good :-)
> Not we we agree (or disagree) on that one.
I am not quite sure how to read this sentence, but I think in an earlier
It seems we are all ok except on the SearchFactory shuffling. Not we we agree
(or disagree) on that one.
On 28 Mar 2014, at 12:41, Hardy Ferentschik wrote:
> Have we by now reached a consensus on wether or not to address the package
> split?
> Anyone against generally against it?
>
> —Hardy
>
Have we by now reached a consensus on wether or not to address the package
split?
Anyone against generally against it?
—Hardy
On 27 Jan 2014, at 14:17, Emmanuel Bernard wrote:
> On Thu 2014-03-27 12:40, Hardy Ferentschik wrote:
>>> the tricky part is that today SearchFactoryIntegrator extends
On Thu 2014-03-27 12:40, Hardy Ferentschik wrote:
> > the tricky part is that today SearchFactoryIntegrator extends
> > SearchFactory, but since SearchFactoryIntegrator needs to say in
> > Engine, it can't depend on SearchFactory. What would you think of
> > breaking this parent-child relation?
> >
On 27 Jan 2014, at 09:17, Guillaume Smet wrote:
> It's really not a big deal if it's compilation errors and we just have
> to reorganize the imports: we clearly see the errors when we upgrade
> so we can fix them easily. You just put it prominently in the release
> notes and it's OK.
My thinkin
On 26 Jan 2014, at 23:11, Sanne Grinovero wrote:
> On 26 March 2014 20:18, Hardy Ferentschik wrote:
>>
>> On 26 Jan 2014, at 20:52, Sanne Grinovero wrote:
>>
>>> The classes in the ORM module are extremely widely used by our primary
>>> target:
>>>
>>> - FullTextQuery
>>> - Search
>>> - Fu
On 27 Mar 2014, at 11:18, Emmanuel Bernard wrote:
>
>>
>>> org.hibernate.search.SearchFactory ->
>>> org.hibernate.search.spi.SearchFactory
>>
>> as Emmanuel said, that's an API currently. I'm inclined to think we
>> should convert it to an SPI, and provide a richer more ORM specific
>>
On 26 Mar 2014, at 20:52, Sanne Grinovero wrote:
> Emmanuel, could you elaborate of what you have in mind as "scalability
> reasons”?
Scale as in having more event provider sources (ORM, Infinispan, X, Y, Z). But
we could accept that ORM has historical and privileged rights and will keep the
Hi,
My 2 cents as an end user of Search: just move them.
It's really not a big deal if it's compilation errors and we just have
to reorganize the imports: we clearly see the errors when we upgrade
so we can fix them easily. You just put it prominently in the release
notes and it's OK.
Most of ou
On 26 March 2014 20:18, Hardy Ferentschik wrote:
>
> On 26 Jan 2014, at 20:52, Sanne Grinovero wrote:
>
>> The classes in the ORM module are extremely widely used by our primary
>> target:
>>
>> - FullTextQuery
>> - Search
>> - FullTextSession
>>
>> and two more lesser ones, but I think the 3 ab
On 26 Jan 2014, at 20:52, Sanne Grinovero wrote:
> The classes in the ORM module are extremely widely used by our primary target:
>
> - FullTextQuery
> - Search
> - FullTextSession
>
> and two more lesser ones, but I think the 3 above are probably "THE
> API”.
That was my thinking as well.
>
It's a though choice.
The classes in the ORM module are extremely widely used by our primary target:
- FullTextQuery
- Search
- FullTextSession
and two more lesser ones, but I think the 3 above are probably "THE
API". To move these out of the way we'd at least need to postpone the
OSGi work for
On 26 Jan 2014, at 13:55, Emmanuel Bernard wrote:
> I don't have a full grasp of the consequences, I'll need to think about
> it.
:-) There might be a couple of other package changes which would make sense
(unrelated to the
split package problem). I guess now is the time to discuss and apply
I don't have a full grasp of the consequences, I'll need to think about
it.
Here are a few comments in the mean time.
SearchFactory is not a SPI, it is used by application developers.
For scalability reasons, I would be tempted to move the orm module
classes out of the root package. But that is def
Hi there,
As part of my work for making Search OSGi ready [1], I am looking into
addressing HSEARCH-1560 [2] which is about
split packages which we have between some of our Search bundles (or modules to
use Maven lingo).
Basically a split package "is caused where two or more bundles export the
15 matches
Mail list logo
