[EasyHack] #44681 port to CLucene from java/Lucene

[Caolán McNamara]

On Fri, 2012-02-10 at 23:11 +0100, Gert van Valkenhoef wrote:
> The code that interfaces with Lucene to do the indexing and searching is 
> complete.

Great.

> I've also looked into where the HelpIndexerTool is currently used, and 
> found these:
> 
>   - xmlhelp/source/cxxhelp/provider/databases.cxx:
> 
>      * In extension mode (enabled by HelpIndexer), through XInvocation
> 
>      * Does not ZIP the result
> 
>   - helpcontent2/util/target.pmk
> 
>      * Called as a command-line tool
> 
>      * ZIPs the result, but already has an alternative code path to do 
> it (the final .ELSE)

The xmlhelp/source/com/sun/star/help/*.java route is the one that sets
the "bExtensionMode". I think this one is which third party extensions
can insert their help into our help system. The cxxhelp is the
straightforward backend of the "search in help" dialogs.

> Especially the "extension mode" seems to be a 
> relic of the convoluted code path (through XInvocation etc.) and doesn't 
> do much more than suppressing error messages.

Yeah, all this started as masses of java code for a custom help format.
Then it got converted to a c++ program, then parts of it basically got
converted back to java and then chopped up to be turned into an
extension.

> couldn't the ZIP creation just always be replaced by this alternative
> code path?

hmph, indeed, seems that way on the face of it. Lets try that.

>   * This implementation is using the master branch of CLucene's git, 
> with clucene-contribs-lib enabled (for CJK support). The released 
> version of CLucene is compatible with Lucene 1.9.x, whereas LibreOffice 
> uses Lucene 2.3.

I don't *think* compatibility between java and c++ file formats matters
to us, if that's what you're getting at here.

>   * I'm not sure exactly how to make my code build as part of the LO 
> build, but could probably figure it out as long as the previous point is 
> addressed.

Presumably just editing l10ntools/source/help/makefile.mk and adding
another target or so in there will do the trick. I can hook this up and
see if how it goes.

>   * CLucene (like Java) uses wide characters throughout, and defines 
> it's own TCHAR type for that. Can we make this play nice with how LO 
> handles strings?
> 
>   * I'm using some Unix headers, are these available on windows or 
> should I use some kind of LO equivalent of them?

Should be basically cross-platform stuff in sal/inc/ to handle any of
that stuff.

>   * I tried replacing the HelpIndexerTool in 
> helpcontent2/util/target.pmk, which seems to work fine, except that I'm 
> returning an error code when the content/caption directory doesn't exist 
> (unlike HelpIndexerTool), which breaks on "shared".

I'll see if I can hook up what you got to our build system, ignoring the
lack of clucene in our tree and assuming availablility of system
clucene, and see how that goes.

C.