Hi Guys
I can take a look at trying to implement something that covers option
3. Also saearchmapping builder uses the getProgrammatic method from
searchconfiguration so it can't be removed unless the use in
searchmapping builder is removed.
Cheers
Amin
Sent from my iPhone
On 8 Dec 2009, a
Well, I am not asking for a preference so much. I was asking for a
solution on how to achieve that :)
Emmanuel
On 8 déc. 09, at 14:11, Hardy Ferentschik wrote:
> I go for 3. I think its nice to not need this additional jar.
>
> --Hardy
>
> On Tue, 08 Dec 2009 08:30:13 -0300, Sanne Grinovero
>
I go for 3. I think its nice to not need this additional jar.
--Hardy
On Tue, 08 Dec 2009 08:30:13 -0300, Sanne Grinovero
wrote:
> Both options 1 and 3 are good for me:
> while it's nice to not need an additional jar, I always use it.
>
> Sanne
>
> 2009/12/8 Emmanuel Bernard :
>> SearchMappin
Both options 1 and 3 are good for me:
while it's nice to not need an additional jar, I always use it.
Sanne
2009/12/8 Emmanuel Bernard :
> SearchMapping has a dependency on Solr's analyzer package which was
> optional in 3.1. The current configuration design makes mandatory as
> the SearchMapping
Also does it make sense to keep
SearchConfiguration#getProgrammaticMapping now that we have the
property approach?
On 8 déc. 09, at 11:58, Emmanuel Bernard wrote:
> SearchMapping has a dependency on Solr's analyzer package which was
> optional in 3.1. The current configuration design makes ma
SearchMapping has a dependency on Solr's analyzer package which was
optional in 3.1. The current configuration design makes mandatory as
the SearchMapping is now used by the SearchFactoryImpl.
Three solutions:
- make the analyzer optional dependency mandatory
- make SearchMapping reflexive
