Re: [hibernate-dev] [hsearch] documentation
On 11 October 2011 15:43, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
Hi,
great, seems we are sharing the same view then.
I will go ahead change the Architecture and Configuration chapters
accordingly.
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
> "hibernate.search.default."
ok. Are we consistent with this though? I am not sure we are, but I will
double
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.
HSEARCH-942
> 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
address
this issue for the 4.0 release, but given the time constraints we skipped
it.
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,
unfortunately,
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
two
for now (and some minor typo fixes I have for the Getting Started section,
I'll
will create a separate pull request for them)
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev