regression...

oops, apparently I forgot to actually complete Summary, sorry...

The only occurances of idxcaption.xsl I see in helpcontent2 and transex3, but
how is  this accessed later? By lucene?

grep -r idxcaption *
helpcontent2/source/auxiliary/.svn/entries:idxcaption.xsl
helpcontent2/util/makefile.mk:ZIP1LIST=main_transform*.xsl idxcaption.xsl
idxcontent.xsl
helpcontent2/util/target.pmk:	$(HELPLINKER) @$(mktmp -mod $(LINKNAME) -hid
$(PRJ)$/helpers$/hid.lst -src $(COMMONMISC) -sty
$(PRJ)$/source$/auxiliary$/embed.xsl -zipdir $(MISC)$/ziptmp$(@:b) -idxcaption
$(PRJ)$/source$/auxiliary$/idxcaption.xsl -idxcontent
$(PRJ)$/source$/auxiliary$/idxcontent.xsl -lang {$(subst,$(LINKNAME)_, $(@:b))}
$(subst,LANGUAGE,{$(subst,$(LINKNAME)_, $(@:b))} $(LINKADDEDFILES))
$(foreach,i,$(LINKLINKFILES) $(COMMONMISC)$/{$(subst,$(LINKNAME)_, $(@:b))}/$i)
-o $@)
transex3/source/help/HelpLinker.cxx:        else if
(args[i].compare("-idxcaption") == 0) 
transex3/source/help/HelpLinker.cxx:				aStrStream << "idxcaption stylesheet
missing" << std::endl;
transex3/source/help/HelpLinker.cxx:		aIdxCaptionPathFileURL +=
rtl::OUString::createFromAscii( "/idxcaption.xsl" );

reassigned
@ ab: something for you?

STARTED, I see no obvious reason so far...

Adjusted target

ab->rene:
idxcaption.xsl and idxcontent.xsl are needed in the context of
creating the Lucene index, but they are not directly accessed
by Lucene. Lucene just processes a set of files stripped down
from the original help files using xslt. This is done in C++.

The helpcontent2 stuff is only used for building helpcontent2.
For the extension case the code in transex3 is used. The path
addressing the xsl files is calculated there using the help
base path $OOO_BASE_DIR/help. The failing calls to xsltParse-
StylesheetFile are done in HelpLinker.cxx / line 88 in the
IndexerPreProcessor ctor. The Java problem probably is only a
subsequent error.

As there is no change in transex3 from m5 to m6 the problem
must be located somewhere else. In a m6 StarOffice I had no
problem installing an extension containing help, but there
of course the help path is the default one.

So what exactly are the appropriate path changes you've mentio-
ned above? I think the fastest way to reproduce the problem
would be to patch my m6 StarOffice to behave in a similar way
and check if something goes wrong with the macro expansion.

> idxcaption.xsl and idxcontent.xsl are needed in the context of
> creating the Lucene index, but they are not directly accessed
> by Lucene. Lucene just processes a set of files stripped down
> from the original help files using xslt. This is done in C++.

OK

> For the extension case the code in transex3 is used. The path
> addressing the xsl files is calculated there using the help
> base path $OOO_BASE_DIR/help.

bad.

> The failing calls to xsltParse-
> StylesheetFile are done in HelpLinker.cxx / line 88 in the
> IndexerPreProcessor ctor. The Java problem probably is only a
> subsequent error.

That I guessed. :)

> As there is no change in transex3 from m5 to m6 the problem
> must be located somewhere else. In a m6 StarOffice I had no
> problem installing an extension containing help, but there
> of course the help path is the default one.

I would have bet m5 worked, but maybe either only by chance or because it was
a en-US only build and m6 with all languages...?

> So what exactly are the appropriate path changes you've mentio-
> ned above? I think the fastest way to reproduce the problem
> would be to patch my m6 StarOffice to behave in a similar way
> and check if something goes wrong with the macro expansion.

No macro expansion involved :)

rengelhard@lxrengelhard:/usr/lib/openoffice/basis3.1/share/registry$ grep -r
\/help *
data/org/openoffice/Office/Paths.xcu:        <node oor:name="$(instpath)/help"
oor:op="fuse"/>
schema/org/openoffice/Office/Common.xcs:          <value>$(instpath)/help</value>
schema/org/openoffice/Office/Common.xcs:          <value>$(instpath)/help</value>

Those I change to /usr/share/openoffice/basisX.Y/help.

Works in 3.1.1

> > For the extension case the code in transex3 is used. The path
> > addressing the xsl files is calculated there using the help
> > base path $OOO_BASE_DIR/help.

> bad.

Indeed, the configuration path should be used. Unfortunately
HelpLinker.cxx has been moved from xmlhelp to transex3 which
is a tooling project trying to avoid any dependency to other
libs as far as possible. It doesn't even use UNO, so acces-
sing the configuration is a problem. I will check this.


> I would have bet m5 worked, but maybe either only by chance or because it was
> a en-US only build and m6 with all languages...?

The xsl files are placed in .../help and that's also the root
for the language folders, e.g. .../help/en. So the problem
should not depend on languages.


> So what exactly are the appropriate path changes you've mentio-
> ned above? I think the fastest way to reproduce the problem
> would be to patch my m6 StarOffice to behave in a similar way
> and check if something goes wrong with the macro expansion.

> data/org/openoffice/Office/Paths.xcu:        <node oor:name="$(instpath)/help"

> Those I change to /usr/share/openoffice/basisX.Y/help.

> Works in 3.1.1

That's what really surprises me. The feature has been introdu-
ced for OOo 3.1 (i83626 "Support full text search in extension
help", http://www.openoffice.org/issues/show_bug.cgi?id=83626)
and, although placed in xmlhelp first, HelpLinker.cxx has al-
ways used this wrong way of getting the help path.

So maybe only the Java crash is new? If I remember correctly
your distribution does not depend on Lucene. Without Lucene
the problem would only become visible if you tried to search
content within the extension's help. The search will always
fail then. Or are you sure that the "xsltParseStylesheetFile
: cannot parse" error did not show up before?

To make sure we don't have a general Java problem here, could
you check if everything works correctly if you place the help
at $OOO_BASE_DIR/help and then install the extension?

> So maybe only the Java crash is new? If I remember correctly
> your distribution does not depend on Lucene. Without Lucene

Correct. But in this case I do* have lucene installed.

> the problem would only become visible if you tried to search
> content within the extension's help. The search will always
> fail then. Or are you sure that the "xsltParseStylesheetFile
> : cannot parse" error did not show up before?

It didn't show up before, I am sure, yes.

> To make sure we don't have a general Java problem here, could
> you check if everything works correctly if you place the help
> at $OOO_BASE_DIR/help and then install the extension?

Yes, it does. (It also does with the said symlink
/usr/lib/openoffice/basisX.Y/help -> /usr/share/openoffice/basisX.Y/help)

Regards,

Rene

apparently I am too tired...

> > Works in 3.1.1
>
> That's what really surprises me. The feature has been introdu-
> ced for OOo 3.1 (i83626 "Support full text search in extension
> help", http://www.openoffice.org/issues/show_bug.cgi?id=83626)
> and, although placed in xmlhelp first, HelpLinker.cxx has al-
> ways used this wrong way of getting the help path.

This of course is nonsense. In 3.1.1 I still have the help in /usr/lib.
Bad me, sorry.

But still, I amn quite qure the failure did *not* happen with m5

> > Works in 3.1.1

> This of course is nonsense. In 3.1.1 I still have the help in /usr/lib.
> Bad me, sorry.

Ok, using the "right" path is a valid explanation... :-)


> But still, I amn quite qure the failure did *not* happen with m5

Anyway, we don't really have to clarify this. In any case
using $OOO_BASE_DIR/help is wrong, so I will focus on fin-
ding a solution for this.

Created attachment 66455 [details]
Patch file for module transex3

Created attachment 66456 [details]
Patch file for module desktop

ab->rene:
I've found a way to fix this without linking transex3 to addi-
tional libraries by passing the Office help path when calling
compileExtensionHelp() from desktop/source/deployment/registry/
help/dp_help.cxx. After learning that changing Common.xcs only
helps after deleting user/registry/cache :-) I tried a diffe-
rent help path and it worked.

For the case you also want to test this in your scenario I've
attached the diffs for module transex3 and desktop. Please
note that the change in desktop depends on the one in transex3,
so transex3 needs to be delivered before building desktop.

I suspect the missing (and now added) if statements in Indexer-
PreProcessor::processDocument() to really cause the crash (at
least it did on Windows). So seeing no crash is not enough to
verify the fix. To be sure after installing the extension fin-
ding something in its help content has to work.

now I get

opying: wiki-publisher.oxt
Enabling: Wiki Publisher
 Enabling: help
error
xsltParseStylesheetFile : cannot parse 
error
xsltParseStylesheetFile : cannot parse 
error
xsltParseStylesheetFile : cannot parse 
error
xsltParseStylesheetFile : cannot parse 
error
xsltParseStylesheetFile : cannot parse 
error
xsltParseStylesheetFile : cannot parse 
 Enabling: WikiExtension.xcs
 Enabling: WikiEditor
 Enabling: mediawiki.jar
 Enabling: Addons.xcu
 Enabling: ProtocolHandler.xcu
 Enabling: WikiExtension.xcu
 Enabling: OptionsDialog.xcu
 Enabling: Filter.xcu
 Enabling: Types.xcu
 Enabling: Paths.xcu

unopkg done.

(yes, it really returns with 0 although there was an error, but that's not a bug
here but unopkg madness)

(the help does appear in the OOo help, but searching for Wiki, WikiPublisher,
"Verbindung Wiki" or anything else doesn't find something unsurprisingly)

ab->rene:
Short update: I switched to Linux and could exactly reproduce
what you have seen, including the Java error message. This ob-
viously is only because Java registered as signal handler.
I don't understand yet why it does work on Windows but not on
Linux. Debugging this now, stay tuned... :-)

The problem was: Surprisingly SvtPathOptions().GetHelpPath()
does not return a file URL (some SvtPathOptions().GetXXX do
so, some don't) but a system path. For reasons I don't under-
stand this doesn't matter on Windows. Obviously the xslt API
accepts this path there. This doesn't work on Linux, so the
help compilation still fails, but the crash is avoided by
the previously added if statements. The solution of course
was to convert the system path to a file URL.

Tested successfully on Windows and Linux -> FIXED

Created attachment 66479 [details]
Corrected desktop patch

cd->ab: Please send to QA or verify issue yourself.

rene->cd: no need to; pmladek and me can confirm the fix (with the updated
desktop.diff) works