> 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
One of today's issues for Hibernate Search had the goal to move this class:
org.hibernate.search.engine.spi.SearchFactoryImplementor
to not have the "SPI" package postfix as we never meant this to be
part of the SPI but rather an internal contract.
While it's an internal contract, it's functional
12 matches
Mail list logo
