FS#39925 - [languagetool] 2.5-1 doesn't keep the directory structure needed by it's .jar files

Attached to Project: Community Packages
Opened by Brice Waegeneire (bricewge) - Thursday, 17 April 2014, 20:52 GMT
Last edited by Andrzej Giniewicz (Giniu) - Thursday, 01 May 2014, 16:44 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Andrzej Giniewicz (Giniu)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:
Some .jar, especially languagetool-commandline.jar, are broken because they have to keep the directory structure as their META-INF/MANIFEST.MF indicate.
The issue was first discuss here: https://github.com/mhayashi1120/Emacs-langtool/issues/8#issuecomment-40659261

Additional info:
* package version: 2.5-1

Steps to reproduce:
$ java -jar /usr/share/java/languagetool/languagetool-commandline.jar

Return:
Exception in thread "main" java.lang.NoClassDefFoundError: org/languagetool/JLanguageTool
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2531)
at java.lang.Class.getMethod0(Class.java:2774)
at java.lang.Class.getMethod(Class.java:1663)
at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486)
Caused by: java.lang.ClassNotFoundException: org.languagetool.JLanguageTool
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 6 more
This task depends upon

Closed by  Andrzej Giniewicz (Giniu)
Thursday, 01 May 2014, 16:44 GMT
Reason for closing:  Won't implement
Additional comments about closing:  Preserving original layout structure would violate arch packaging standards. I've crated patched emacs-langtool that uses arch layout and it should be ok.
Comment by Andrzej Giniewicz (Giniu) - Friday, 18 April 2014, 09:13 GMT
It's not that easy, and I actually tried it before - languagetool is packaged along with https://wiki.archlinux.org/index.php/Java_Package_Guidelines and works well by itself, and with vim-languagetool, so I'd rather keep it like it is. In my opinion it is better solution to create languagetool-emacs, with very small one-two lines of code patch, to make it work with current version of LT (approach I took with vim-languagetool) - if we try to keep original package structure, we'd violate principle of keeping only .jar files in /usr/share/java/*. Same arguments apply to most Java applications as they need to have their files in classpath, so if we start violating it, we might as well drop all Java apps into /opt.

I will look into packaging this emacs plugin to be compatible with LT from community, in the meantime, you can just unzip official languagetool into /usr/local/LanguageTool-2.5 and make emacs pick it instead.
Comment by Andrzej Giniewicz (Giniu) - Thursday, 01 May 2014, 16:41 GMT
Try using https://aur.archlinux.org/packages/emacs-langtool/ - with this, you need no jar or java settings, just (require 'langtool) and it should work. I installed Emacs to check it, and it seems to work, at least for Polish language. If you need any further help with emacs-langtool package, please comment there and I will try to fix it.

Loading...