> On 08 Dec 2014, at 14:34, Hardy Ferentschik wrote:
>
> On Mon, Dec 08, 2014 at 12:07:45PM +, Sanne Grinovero wrote:
>>> 2. The name. SearchFactoryImplementor is something which implements
>>> SearchFactory. However,
>>> one of the latest changes was to make SearchFactory a stand alone c
On Mon, Dec 08, 2014 at 12:07:45PM +, Sanne Grinovero wrote:
> > 2. The name. SearchFactoryImplementor is something which implements
> > SearchFactory. However,
> >one of the latest changes was to make SearchFactory a stand alone class
> > of the orm module.
> >SearchFactory is now on
On 8 December 2014 at 10:13, Hardy Ferentschik wrote:
> Hi,
>
>> One of today's issues for Hibernate Search had the goal to move this class:
>>
>> org.hibernate.search.engine.spi.SearchFactoryImplementor
>
> Well, for me there is more to this than just moving. There are two issues imo.
>
> 1. The
Ok that sounds like the best compromise. I'll adjust my open PR.
Thanks!
Sanne
On 8 December 2014 at 10:18, Hardy Ferentschik wrote:
> Hi,
>
> On Mon, Dec 08, 2014 at 10:47:25AM +0100, Emmanuel Bernard wrote:
>> BTW, can’t you isolate those classes in a dedicated package still marked
>> `impl`
Hi,
On Mon, Dec 08, 2014 at 10:47:25AM +0100, Emmanuel Bernard wrote:
> BTW, can’t you isolate those classes in a dedicated package still marked
> `impl` but have it exposed to OSGi?
That was my suggestion as well. It is probably not the worst alternative. It
moves the class out of the spi
pack
Hi,
> One of today's issues for Hibernate Search had the goal to move this class:
>
> org.hibernate.search.engine.spi.SearchFactoryImplementor
Well, for me there is more to this than just moving. There are two issues imo.
1. The location. org.hibernate.search.engine.spi implies after our defini
After reading this thread, `family` or `private` feel better than `friend`
BTW, can’t you isolate those classes in a dedicated package still marked `impl`
but have it exposed to OSGi?
After all all this "shared but not shared because we decided to cut our
software in many pieces“ is a bit of an
Thanks all,
so I went for the "friend" package name, adding a brief notice in the javadocs.
https://github.com/Sanne/hibernate-search/blob/HSEARCH-1739/engine/src/main/java/org/hibernate/search/engine/friend/package-info.java
Sanne
On 6 December 2014 at 16:02, Steve Ebersole wrote:
>> Sometimes
>
> Sometimes it's just convenience; we have an "util.JNDIHelper" which is
> needed in several modules (Massindexer statistics, JMS lookups, etc..)
> and I don't think we should expose it as an API nor that another
> project like Infinispan Query should ever use it.
>
It's funny you bring up JNDIH
Thanks for the quick feedback!
On 5 December 2014 at 21:35, Emmanuel Bernard wrote:
> If hibernate-search-orm needs it, it's likely that infinispan-query
> could also make use of that contract. After all, infinispan-query is
> very similar conceptually to our ORM integration albeit simpler.
I ha
If hibernate-search-orm needs it, it's likely that infinispan-query
could also make use of that contract. After all, infinispan-query is
very similar conceptually to our ORM integration albeit simpler.
Isn't it our definition of a SPI?
If you don't change your mind, I am not a big fan of the inte
11 matches
Mail list logo
