Apache OpenOffice (AOO) Bugzilla – Issue 93559
Report Builder 1.0.5 cannot be installed
Last modified: 2008-10-10 06:24:15 UTC
SRB 1.0.5 (see URL) cannot be installed. Extension manager reports an error, that the license text cannot be found. Problem has been verified on Kubuntu, Debian, WinXP. The problem seems to be caused by a inconsistent license-id ("en-US" vs. "lic-en-US"): <simple-license accept-by="admin" default-license-id="en-US" > <license-text xlink:href="registration/license_en-US.txt" lang="en-US" license-id="lic-en-US"/> </simple-license>
attach the screenshot I took
Created attachment 56291 [details] Screenshot
In the meantime we found out that it wors in an English environment but it doen't work in all other environments, e.g english version with German langpacks.
Under WinXP, and en-US version, and Hungarian langpack SRB 1.0.5-beta works. SRB was installed, before Hu langpack installation.
Installation will work in en-US environments (or en-US Office installation), as the language attribute of the license tag is correct. Installation will only fail in non en-US environments, as the default licenses id ("en-US") is not defined in the list of licenses.
Seems to be a problem in the makefile extensions_post.mk or in the perl script licinserter.pl. Please have a look at it. Thanks.
Under openSuSE 11.0 SRB 1.0.5 works with Hu langpack, installation problems same.
@r4zoli do you work with the HU UI or with the English UI at the time of installation It works for me also if I change the UI Language from German to English then I can install the extension.
I used en UI, than installation works. Hu UI no installation. May be the interpretation of word "works", caused some misunderstanding. If I can install SRB with en-US UI, after that it works, as desired. I interpreted your text, if you installed SRB it does not work, not pure installation process, what you write about.
Created attachment 56326 [details] default to an existing entry
the attached patch applied to the sourcereportbuilder/util/ description.xml) or the according change to the description.xml in the oxt file fixes the problem here.
.
Looks good.
The patch has been applied as masterfix on OOO300m6. I can't apply the patch on DEV300 yet.
I test it with OOO300_m6 German version and it doesn't work. so I reopen this Issue
Which version of the SRB did you use? (really, I still hope for a future where you tell this before asking you :) SCNR :)The same as last time? If so, that's the problem - the fix was in the extension, and I am not sure Ocke uploaded a new version of it.
@ fs sorry but kz wrote the fix is as masterfix in m6. That was the reason I don't wrote something about my SRB. Sorry for misunderstanding the context.
no problem. So - did you use the "old" version, or a new one obtained from somewhere else?
note: I uploaded a beta-2 of SRB 1.0.5 to ftp://qa-upload.services.openoffice.org/SRB, which was taken from an OOO300.m6 build - please try this version.
the new version fs announced works set fixed again
thanks for testing this that quickly, and reporting back!
verified with the latest build of SRB 1.0.5 on extensions.services.openoffice.org
-> closed
I have another installation failure from the Extension Manager with OOO300m9. Gentoo/amd64 linux. The dialog box shows 'error: invalid header field'. If I change the manifest entry 'UNO-Type-Path' of sun-report-builder.jar from 'UNO-Type-Path:' to 'UNO-Type-Path: .' it loads fine. I wonder where it should point to.
The last version 1.0.5 from website doesn't work for me in one test. To confirm it I need further access on 64 bit
Grabbing
Could you please take over. Thanks.
The sun-report-builder.jar contained in <ftp://qa-upload.services.openoffice.org/SRB/sun-report-builder-1.0.5-beta-2.oxt> contains a META-INF/MANIFEST.MF that contains a line containing the text "UNO-Type-Path:" followed by SPACE, CR, LF. This is legal syntax according to <http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html#Section-Specification>. Changing the data encoded in the UNO-Type-Path header from the empty string to "." as you suggest would change the semantics, see <http://wiki.services.openoffice.org/w/index.php?title=Documentation/DevGuide/WritingUNO/Possible_Structures_for_Java_Components#Additional_UNO_Types>. @geki: Since the error you get is "invalid header field," I assume that the Java version your OOo is using has problems with the JAR specification, instead of there being problems with the semantics of the extension's UNO-Type-Path. Please verify by trying with a different Java version (even from a different vendor, if possible).
Hmm, last test was successful. I will see on next build and report to jdk devs if necessary. I wonder why I got assigned to the bug. ;) May it be jar spec violation or user error, my error is invalid. And I still wonder how empty entries could be of any use, but o well ... ;) Anyone, feel free to take over. :)
"I wonder why I got assigned to the bug. ;) May it be jar spec violation or user error, my error is invalid.": @oj: Please take over again (I lost track what else, if anything, apart from geki's---now deemed invalid---<#desc25> is still open). "And I still wonder how empty entries could be of any use, but o well ... ;)": See "For backwards compatibility, if you do not include the UNO-Type-Path manifest entry at all, the UNO runtime assumes that the current jar does contain UNO types." <http://wiki.services.openoffice.org/w/index.php?title=Documentation/DevGuide/WritingUNO/Possible_Structures_for_Java_Components#Additional_UNO_Types>
Nothing more is open. I now set it to fixed again as it was fixed before :-) And closing it afterwards.