Hi, that's not the best news we could hear :(
I don't exactly remember which jar contained the XGrammarChecker class but you could try copying this into Cogroo directory while replacing the main Cogroo jar with a jar that contains the classpath setting to search for this jar in the current directory. So basically the script should copy two files. And then try unopkg... I guess this could be scripted for Windows and Mac & Unices (one batch file and one shell script). I don't have access to my development machine so I cannot experiment right now, so I'd be grateful if you could :) The script could first call unopkg to see if LT or Cogroo is left over, and only then do the dirty job. Regards Marcin Dnia 29 stycznia 2009 2:33 William Colen <[email protected]> napisał(a): > Marcin, > > I tried that but without success. First I tried with Cogroo and it failed. > To make sure it wasn't something on Cogroo side I tried with LT and it also > failed :( > > 1. Installed OOo 3.0.0 > 2. Installed LT 0.9.5 > 3. Installed OOo 3.0.1 > > See the unopkg output: > > C:\Program Files\OpenOffice.org 3\program>unopkg remove > org.openoffice.languaget > ool.oxt > > ERROR: [jni_uno bridge error] UNO calling Java method writeRegistryInfo: > non-UNO > exception occurred: java.lang.NoClassDefFoundError: > com/sun/star/linguistic2/XG > rammarChecker > java stack trace: > java.lang.NoClassDefFoundError: com/sun/star/linguistic2/XGrammarChecker > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(Unknown Source) > at java.security.SecureClassLoader.defineClass(Unknown Source) > at java.net.URLClassLoader.defineClass(Unknown Source) > at java.net.URLClassLoader.access$000(Unknown Source) > at java.net.URLClassLoader$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at java.net.FactoryURLClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at > com.sun.star.comp.loader.RegistrationClassFinder.find(RegistrationCla > ssFinder.java:67) > at > com.sun.star.comp.loader.JavaLoader.writeRegistryInfo(JavaLoader.java > :433) > Caused by: java.lang.ClassNotFoundException: > com.sun.star.linguistic2.XGrammarCh > ecker > at java.net.URLClassLoader$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClassInternal(Unknown Source) > ... 14 more > > > Thanks > William > > On Wed, Jan 28, 2009 at 8:55 PM, Marcin Miłkowski wrote: > > > Mathias Bauer pisze: > > > > Joachim Lingner wrote: > >> > >> Thomas Lange - Sun Germany - ham02 - Hamburg schrieb: > >>> > >>>> Hi, > >>>> > >>>> Marcin Miłkowski wrote: > >>>> > >>>> Hi, > >>>>> > >>>>> the problem is that the Java API has changed. So our extension that > >>>>> used the old API cannot find classes in new jars, and because of this > >>>>> fact > >>>>> you cannot uninstall it via the Extension Manager. Moreover, you cannot > >>>>> even > >>>>> specify the maximum allowed version for an extension (we wanted to do > >>>>> so), > >>>>> as this was introduced in 3.1, so it doesn't work for 3.0.0. > >>>>> > >>>>> Probably another workaround would be to manually copy the old jar to > >>>>> the extension directory and add it to the classpath, then use unopkg to > >>>>> remove the extension. In Linux, this is probably easily scriptable. In > >>>>> Windows, I'm not so sure... If you have any other suggestions, we will > >>>>> be > >>>>> grateful. > >>>>> > >>>>> This is a limitation of the Extension infrastructure, actually. The > >>>>> required maximum version feature is already implemented so this is > >>>>> already > >>>>> fixed for future versions of OOo. > >>>>> > >>>>> Regards > >>>>> Marcin > >>>>> > >>>>> > >>>> I do not consider the implementation of a maximum version to be a fix > >>>> for not being able to uninstall/upgrade extensions, even though the API > >>>> incompatibility has happened. > >>>> > >>>> If it is about updating the Office: If on the next start, after the > >>>> office update, incompatible extensions are found those should be > >>>> automatically disabled before the office gets started. Or at least they > >>>> should be disabled and then the Office automatically restarted once more > >>>> if necessary. > >>>> Firefox and Thunderbird for example seem to be able to do that... > >>>> > >>> Yup. Missing feature. Although, if the removal fails because of the Java > >>> problem, then certainly disabling the extension would fail as well. > >>> > >> > >> This is another good argument for one of my feature wishes: please allow > >> the registration of binaries to be based on registry files (preferable > >> human readable ones), don't require them to be executable or loadable > >> for registration or deregistration. It would also be a performance win > >> for the extension manager. > >> > >> The same works pretty well for COM components on Windows: you can call > >> regsvr32.exe either on a libarary or on a reg file. > >> > > > > Daniel Naber has just found that unopkg can fix the problem :) > > > > So basically you can do it like this: > > > > unopkg remove org.openoffice.languagetool.oxt > > > > But it's clearly a defect that the Extension Manager is unable to do so. > > > > Regards > > Marcin > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
