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] > >
