[hibernate-dev] [hsearch] documentation
sanne at hibernate.org
Tue Oct 11 10:52:55 EDT 2011
On 11 October 2011 15:43, Hardy Ferentschik <hardy at hibernate.org> wrote:
> great, seems we are sharing the same view then.
> I will go ahead change the Architecture and Configuration chapters
> It won't be in the release tomorrow, but definitely for the Final.
>>> * properties of the form org.hibernate.search.xyz are default values
>>> which apply for any index manager if not overridden explicitly
>> warning it's actually
> ok. Are we consistent with this though? I am not sure we are, but I will
> check. But basically that was just a typo.
Yes we are consistent with this. In fact IndexManager implementations
only receive the properties from under these paths so anything
inconsistent wouldn't be able to work.
>> a- no "org." in the front
>> b- it must end with ".default" to be picked up by other IndexManagers
>> on a) : shall we relax this and allow "org." prefix too? This bytes
>> myself periodically
> Didn't we have the discussion once before? We do it this way, because its
> what we do in Core? But I think even there we have some org.hibernate.xyz
> and some hibernate.xyz
> I have no strong opinion on transparently allowing the 'org' prefix.
Ok, just wondering as this is definitely not the most urgent change;
I'll open an issue, seems a good starting point for a new contributor.
>> on b) : I really think this ".default" business got out of hand; it
>> made sense in initial days as there wasn't much to configure, but
>> nowaday? Is it still self-speaking that "default" relates to the
>> IndexManager / indexes
> No it is not and I am not so happy about the 'default' value either.
> As you say, it gets too confusing. Question is what to about it?
> Deprecating the default values? Or even removing them.
>> We have an issue open around reviewing configuration properties, this
>> thought was one of the reason to open it:
>> HSEARCH-859 - Review names and composition of configuration properties
> I know. I mentioned it to Emmanuel today. It would have been better to
> this issue for the 4.0 release, but given the time constraints we skipped
WDYM ? 4.0 was not released yet, if we see a change which should be
done, we should be able to make them now.
> This means these changes need to be deferred until 4.1 where we then,
> also have to care about backward computability. Unfortunate, really.
>> Sounds all good. I'm not touching docs myself to avoid conflicts, but
>> if you want to assign me some tasks in isolated chapters.
> Changing anything outside chapter 2 and 3 is safe. I will focus on these
> for now (and some minor typo fixes I have for the Getting Started section,
> will create a separate pull request for them)
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev