I had a nifty small tool written to convert spreadsheets to plain text.
Since it was my private hacker tool, it relied on OpenOffice 2.x to read the files.
But when I installed OpenOffice 3 and tried to get it get it to run, I failed miserably, because I'm either missing some JAR files or half the classes have been replaced.
I'm including all five JAR files from URE/Java (URE: UNO
Runtime Environment, a subset of OpenOffice.org hosting and
managing UNO components) and am still missing these classes:
com.sun.star.frame.XComponentLoader
com.sun.star.frame.XController
com.sun.star.frame.XDesktop
com.sun.star.frame.XModel
com.sun.star.frame.XStorable
com.sun.star.sheet.XSpreadsheet
com.sun.star.sheet.XSpreadsheetDocument
com.sun.star.sheet.XSpreadsheetView
com.sun.star.text.XTextDocument
Any pointers?
I found what I was missing.
I had to include the following jars
URE/java/juh.jar
URE/java/jurt.jar
URE/java/ridl.jar
Basis/program/classes/unoil.jar
The last one I was missing before - note the German OOo version.
And, something I didn't have to do before, I had to include the path to the OOo executables, e.g.
c:/program/OpenOffice.org 3/program/
After that and without changing code it worked just like before.
So, Brian, UNO's API is stable even between major releases. It was just the classpath I had to fix.
Related
I am trying to use a native library on an ARM based Mac, i.e. an M1 processor. There are several JVMs available for that architecture, for example Azul or Liberica. Both come with a JavaNativeFoundation.framework dynamic library, which is necessary to use any JNI code. However, the framework does not have a Versions folder that contains the major version of the framework (like A). Instead, the library is just contained in the top level folder:
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/_CodeSignature
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/_CodeSignature/CodeResources
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/JavaNativeFoundation
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/Resources
/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/JavaNativeFoundation.framework/Resources/Info.plist
Trying to run my program I get
[java] AquaNativeSupport: Unable to load library libvaqua.dylib: /private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib: dlopen(/private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib, 0x0001): Library not loaded: #rpath/JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation
[java] Referenced from: /private/var/folders/tg/06858t0j3w10js_5hb3k5frw0000gn/T/libvaqua4883847212092667097.dylib
[java] Reason: tried: '/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/server/./JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file),
'/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/lib/server/../JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file),
'/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/bin/./JavaNativeFoundation.framework/Versions/A/JavaNativeFoundation' (no such file),
'/Library/Java/JavaVirtualMachines/zulu-16.jdk/Contents/Home/bin/../lib/JavaNativeFoundation.framework/Versions/A/Java
It looks like the output is incomplete, but anyway: You can see that java is trying to load the framework from a Versions/A/ subfolder of the framework, which does not exist anywhere.
If I create that subfolder and create a softlink to the existing binary JavaNativeFoundation in it, then the application loads the JNI code just fine.
Given that situation I have two questions:
Why are the Frameworks in both Azul/zulu and Liberica missing the Versions structure?
Is there a way to work around that problem by loading the Framework in a different way? Some "dontusemajorversion" flag?
Thank you for your help.
I'd like to get the sources of
glassfish-embedded-all-3.1.2.2.jar.
But
http://repo1.maven.org/maven2/org/glassfish/main/extras/glassfish-embedded-all/3.1.2.2/glassfish-embedded-all-3.1.2.2-sources.jar
does only contain the pom.xml and the MANIFEST.MF, not any java source code.
I'm mainly interested in the part
org.eclipse.persistence.internal.jpa (Bundle-Version: 2.3.4.v20160520-8886999)
which should be available per Eclipse Public License.
But if I search for org.eclipse.persistence.internal.jpa.EntityManagerImpl on grepcode, a lot of versions from 1.0.1 to 2.6.1-RC1 are available, but between 2.1.1 and 2.4.2 is a big gap.
My first guess was that maybe there hasn't been a change from 2.1.1 to 2.3.4, so this could be "my" version, but this version contains only javadoc at line 488 where "my" stacktrace (on the PROD server) raises an exception.
So this can not be the correct version, so:
Where can I find the correct and (almost) complete sources of
glassfish-embedded-all-3.1.2.2.jar ?
I am following this guide to incorporate an activation expression (from core expressions) into my own extension point. As the guide says, I have created my extension point schema as follows:
But as you can see, I get errors for the referenced elements. (Element 'xxx' is not defined).
Actually, when I switch to the definition tab and double-click in the schema URL in the Schema inclusions list, I get the error message schema:/org.eclipse.core.expressions/schema/expressionLanguage.exsd could not be found.
My first suspicion was that something might have changed here for Eclispe Kepler, but the docs say anything about it. And I imported the org.eclipse.core.expressions plug-in from the Plug-Ins view into my workspace temporarily and checked if the referenced schema is actually where it is supposed to be (which it is). So this seems to be ok.
My next suspicion was that this had something to do with my target platform, so I double-checked my target platform, but I don't see any issue here. It includes (among others) the features
org.eclipse.platform 4.3.2.v20140221-1852
org.eclipse.platform.source 4.3.2.v20140221-1852
org.eclipse.rcp 4.3.2.v20140221-1700
org.eclipse.rcp.source 4.3.2.v20140221-1700
and the Core Expressions bundles are there as well:
org.eclipse.core.expressions 3.4.501.v20131118-1915
org.eclipse.core.expressions.source 3.4.501.v20131118-1915
I am currently stuck. Any pointer what else I can check or how I can fix this is appreciated.
Does your plug-in file (org.eclipse.core.expression.xxx.jar) actually have the schema file?
Today I had same problem and found that the jar file doesn't have the schema file.
I downloaded source jar file which have the schema file (Actually I found the source jar file from : http://grepcode.com/snapshot/repository.grepcode.com/java/eclipse.org/4.2/org.eclipse.core/expressions/3.4.400) and put the schema file into my jar file and it solves the problem.
Good luck.
Ok, several chaotic attempts of
reloading the target platform
cleaning all projects
restarting Eclipse with -clean switch
seems to have done the trick. I am not sure what caused this, but now the error has vanished (and I hope it stays this way).
I've been trying to get my Emacs config for Java development working. It's pretty good - I've gotten malabar-mode working and have GNU Global working for tag browsing. The one thing I can't get working is getting semanticdb to use gnu global properly. None of my imports are found.
First, this is a Maven multi-module project with all sources checked out from the top-level root project folder. All other projects are below this one in the directory tree. There is a single GTAGS database in this root folder covering everything.
Things that work:
M-x gtags-find-tag RET symbol RET works fine, so the database is good and global can find it.
M-x cedet-gnu-global-version-check works and reports that my version is good.
M-x cedet-gnu-global-expand-filename works
M-x semanticdb-find-test-translate-path shows a "GNU Global Search Table" when in a Java buffer
I have the JDK source folder set as a system include folder, so core Java imports are parsed properly.
My java config is as follows (cedet initialization is earlier in the file):
(add-local-load-path "malabar/lisp")
(require 'malabar-mode)
(setq malabar-groovy-lib-dir (concat emacs-local-site-lisp "malabar/lib"))
(add-to-list 'auto-mode-alist '("\\.java\\'" . malabar-mode))
;; enable semanticdb support for gnu global
(when (cedet-gnu-global-version-check t)
(semanticdb-enable-gnu-global-databases 'java-mode))
(add-hook 'java-mode-hook
(lambda ()
(gtags-mode 1)))
(add-hook 'java-mode-hook 'flymake-mode-on)
(defun my-java-flymake-init ()
(list "javac" (list (flymake-init-create-temp-buffer-copy
'flymake-create-temp-with-folder-structure))))
(add-to-list 'flymake-allowed-file-name-masks
'("\\.java$" my-java-flymake-init flymake-simple-cleanup))
(add-hook 'java-mode-hook
'(lambda ()
(semantic-add-system-include (getenv "JAVA_HOME") 'java-mode)))
The answer is related to how your projects are set up, and if you are using EDE. EDE is Emacs Development Envornment (play on IDE) and is how CEDET tracks which files belong to your project. That limiter is related to both performance (searching less stuff) and preventing configurations from one project bleeding into another.
Unfortunately, Maven is not yet supported in CEDET/EDE. You can, however, just tag the root of your project, and I'd guess ede-cpp-root (usually used for C++ projects) might be sufficient. We should probably make a java version of that.
Anyway, EDE can be configured to use GNU Global to find files quickly (see the manual for GNU Global support with both EDE and Semantic) but your GTAGS file needs to be at the project root.
If you are in project-1, and expect to jump to files in project-2, and GTAGS is as the root of project-1, then it won't work. You'd have to move your GTAGS file and EDE project up to a common parent directory.
In your current setup, if everything is already under a common directory with GTAGS, then it is more likely you just need to setup an EDE project to hang the GTAGS file finding feature.
There are threads in the cedet-devel mailing list archive of a couple folks who have had some success in this.
I am trying to use emacs and slime to connect to swank to live code using Overtone. I have the whole thing pretty much working, but when i try to run
(ns foo
(:use [overtone.live]
[overtone.inst.synth]))
(definst bar [] (saw 220))
I get the error 'Could not locate overtone/live__inti.class or overtone/live.clj on classpath:' Which i gather basically means that the class files are not where it is looking for them. I am not sure what to do to fix this.
Important note: Slime/Swank/Cake are deprecated means of connecting Overtone and Emacs. Instead, consider using nREPL via Leiningen 2+ and CIDER
it looks like you haven't got the Overtone jar on the classpath. Things to check:
You have overtone-X-Y-X.jar in your project's lib directory
Your project isn't called Overtone (that can cause issues with tools like lein)
Finally, you might want to take a look at this setup video: http://vimeo.com/25190186 which describes the process of getting an Overtone dev environment setup.
Good luck and come join the mailing list and share your thoughts: http://groups.google.com/group/overtone
Have you tried confirming that overtone is in your java classpath?
(System/getProperty "java.class.path")
It's most likely a temporary fix, as I'm just getting my feet wet with clojure and overtone, but I included overtone as a global dependecy in my ~/.cake directory and installed it with:
cake deps --global
Additionally, I'd reccomend updating to the latest version of overtone as it looks like the vimeo link is a few versions behind what is currently reflected on clojars:
http://clojars.org/overtone