Marcin Good news! I could try it today. Instead of recompile things, I tried to override the old jar with the new one that don't require the XGrammarChecker class. It was possible to remove using unopkg.
I'm going to try a script to uninstall it in Windows. I can try it with LT also. Unfortunately I don't know how to write shell scripts. Regards William 2009/1/29 William Colen <[email protected]> > I can't do that today also. I'll do it tomorrow. > > Thank you! > William > > On Thu, Jan 29, 2009 at 11:19 AM, Marcin Miłkowski <[email protected]> wrote: > >> 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] >> >> >
