Hi, Alain M., from the OOo Brazilian community, suggested the following solution:
1. Remove OOo 3.0.1 2. Install OOo 3.0.0 3. Remove the GC extension 4. Install OOo 3.0.1 5. Install the new GC extension I tried it with Windows XP and it works fine. Regards, William 2009/1/29 William Colen <[email protected]>: > 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] >>> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
