We Keep Coding

NetBeans 8.0 Gradle Plug-in (for LibGDX)

I wanted to start using LibGDX but since they switcher to gradle recently I folowed their guides.
According to those,I installed the plugin Gradle support on NetBeans 8.0 and when I try to open a Gradle Project
I get the error:
Failed to load Gradle Project:test
and when i go to the stacktrace, i get this
Issue 1
Requested project: C:\Users\Halo\Downloads\test
Stack trace:
org.gradle.tooling.GradleConnectionException: Could not run build action using Gradle distribution 'http://services.gradle.org/distributions/gradle-1.10-all.zip'.
at org.gradle.tooling.internal.consumer.ResultHandlerAdapter.onFailure(ResultHandlerAdapter.java:55)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:57)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
at org.gradle.tooling.internal.consumer.DefaultBuildActionExecuter.run(DefaultBuildActionExecuter.java:43)
at org.netbeans.gradle.model.GenericModelFetcher.getModels(GenericModelFetcher.java:166)
at org.netbeans.gradle.project.model.NbGradle18ModelLoader$ProjectModelFetcher.getModels(NbGradle18ModelLoader.java:374)
at org.netbeans.gradle.project.model.NbGradle18ModelLoader.loadModels(NbGradle18ModelLoader.java:79)
at org.netbeans.gradle.project.model.GradleModelLoader.loadModelWithProgress(GradleModelLoader.java:496)
at org.netbeans.gradle.project.model.GradleModelLoader.access$600(GradleModelLoader.java:57)
at org.netbeans.gradle.project.model.GradleModelLoader$6.run(GradleModelLoader.java:364)
at org.netbeans.gradle.project.tasks.GradleDaemonManager.runNonBlockingGradleTask(GradleDaemonManager.java:24)
at org.netbeans.gradle.project.tasks.GradleDaemonManager.access$100(GradleDaemonManager.java:14)
at org.netbeans.gradle.project.tasks.GradleDaemonManager$2.run(GradleDaemonManager.java:105)
at org.netbeans.gradle.project.tasks.GradleDaemonManager$3.run(GradleDaemonManager.java:130)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
Caused by: org.gradle.api.GradleException: Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at http://gradle.org/docs/1.10/userguide/gradle_daemon.html
Please read below process output to find out more:
-----------------------
at org.gradle.launcher.daemon.bootstrap.DaemonGreeter.parseDaemonOutput(DaemonGreeter.java:34)
at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startProcess(DefaultDaemonStarter.java:109)
at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startDaemon(DefaultDaemonStarter.java:90)
at org.gradle.launcher.daemon.client.DefaultDaemonConnector.startDaemon(DefaultDaemonConnector.java:95)
at org.gradle.launcher.daemon.client.DefaultDaemonConnector.connect(DefaultDaemonConnector.java:72)
at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:149)
at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:74)
at org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:42)
at org.gradle.tooling.internal.provider.DaemonBuildActionExecuter.execute(DaemonBuildActionExecuter.java:29)
at org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:53)
at org.gradle.tooling.internal.provider.LoggingBridgingBuildActionExecuter.execute(LoggingBridgingBuildActionExecuter.java:30)
at org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:106)
at org.gradle.tooling.internal.provider.ProviderConnection.run(ProviderConnection.java:100)
at org.gradle.tooling.internal.provider.DefaultConnection.run(DefaultConnection.java:143)
at org.gradle.tooling.internal.consumer.connection.ActionAwareConsumerConnection.run(ActionAwareConsumerConnection.java:40)
at org.gradle.tooling.internal.consumer.DefaultBuildActionExecuter$1.run(DefaultBuildActionExecuter.java:53)
at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:82)
at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:58)
at org.gradle.tooling.internal.consumer.connection.LoggingInitializerConsumerActionExecutor.run(LoggingInitializerConsumerActionExecutor.java:44)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor$1$1.run(DefaultAsyncConsumerActionExecutor.java:55)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
In the code it says that it's caused by Daemon, can someone explain to me how to fix it? it's really torturing my head and I'm about to give the finger to LibGDX and smash my pc into smitherings.
I'll add that I've tried to use the gradlew inside the folder of the project that LibGDX has built (using cmd) but i've got no clue to what to do and, apart for the Gradle support plug-in i've got nothing else about gradle on my pc

I had same problem, turned out to be a proxy problem. Gradle does not see your proxy setting and you have to add them manually to the gradle.properties file in the project.
It then donwloads all relevant jar files when you build the project.
Used this page setup : http://www.gradle.org/docs/current/userguide/build_environment.html

cannot run jenkins, even after clearing it's directory

Tried to upgrade jenkins today. It doesn't start anymore.
Even if i try to remove its directory, it recreates it cleanly but then crashes with following log.
[#|2013-04-24T07:24:49.849+0200|INFO|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=106;_ThreadName=Thread-2;|jenkins was successfully deployed in 3,800 milliseconds.|#]
[#|2013-04-24T07:24:50.100+0200|INFO|glassfish3.1.2|jenkins.InitReactorRunner|_ThreadID=152;_ThreadName=Thread-2;|Listed all plugins|#]
[#|2013-04-24T07:24:50.100+0200|SEVERE|glassfish3.1.2|jenkins.InitReactorRunner|_ThreadID=152;_ThreadName=Thread-2;|Failed Loading plugins
java.lang.NullPointerException
at hudson.PluginManager$2$1.run(PluginManager.java:324)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at jenkins.model.Jenkins$7.runTask(Jenkins.java:888)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
|#]
[#|2013-04-24T07:24:50.102+0200|SEVERE|glassfish3.1.2|hudson.WebAppMain|_ThreadID=143;_ThreadName=Thread-2;|Failed to initialize Jenkins
org.jvnet.hudson.reactor.ReactorException: java.lang.NullPointerException
at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246)
at jenkins.InitReactorRunner.run(InitReactorRunner.java:43)
at jenkins.model.Jenkins.executeReactor(Jenkins.java:899)
at jenkins.model.Jenkins.<init>(Jenkins.java:801)
at hudson.model.Hudson.<init>(Hudson.java:81)
at hudson.model.Hudson.<init>(Hudson.java:77)
at hudson.WebAppMain$2.run(WebAppMain.java:214)
Caused by: java.lang.NullPointerException
at hudson.PluginManager$2$1.run(PluginManager.java:324)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259)
at jenkins.model.Jenkins$7.runTask(Jenkins.java:888)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
|#]
Jenkins 1.512 on Glassfish 3.1.2.2
EDIT: version 1.421 works. Version 1.422 fails. This is consistent, even after wiping jenkins directory.

Found this, and I had 2 virtual servers:
https://gist.github.com/andrewg4153/3693577
If you have a Glassfish domain with multiple virtual servers, you will
be tempted to select them all when you deploy the Jenkins CI web
application. This is a bad thing to do, as the Jenkins core code
contains a singleton class:
http://sorcerer.jenkins-ci.org/source-view.html?jenkins/model/Jenkins.js#678
When you do this, you'll get the following in your logs:
java.lang.IllegalStateException: second instance at
jenkins.model.Jenkins.(Jenkins.java:744) at
hudson.model.Hudson.(Hudson.java:81) at
hudson.model.Hudson.(Hudson.java:77) at
hudson.WebAppMain$2.run(WebAppMain.java:217) Just deploy to one of the
virtual servers, and everything will be okay.
I deployed on 1 of them and it now works!
Well, I guess it's the bug to fix...

According to the stack trace you provided: Perhaps there is some missing plug-in Task Scanner Plugin or its dependency that is breaking your Jenkins instance?
Caused by: java.lang.NullPointerException
at hudson.PluginManager$2$1.run(PluginManager.java:324)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146)

Jenkins version 1.422 had a booting issue. 1.423 was supposed to fix it. My suggestion would be to clean install 1.423 and see if that solves the issue. If it does, try upgrading from there.

JAXB related exception

When I attempt to connect to my web service, which is running on the local machine, I get the following exception:
java.lang.ExceptionInInitializerError
at com.sun.xml.internal.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:254)
at com.sun.xml.internal.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:82)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)
at com.sun.xml.internal.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:232)
at com.sun.xml.internal.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:460)
at com.sun.xml.internal.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:233)
at com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:95)
at com.sun.xml.internal.ws.transport.http.server.WSHttpHandler.handle(WSHttpHandler.java:80)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:65)
at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:65)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:68)
at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:557)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:65)
at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:529)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
Caused by: java.lang.ClassCastException: com.sun.xml.bind.v2.runtime.JAXBContextImpl cannot be cast to com.sun.xml.internal.bind.api.JAXBRIContext
at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.<clinit>(SOAPFaultBuilder.java:533)
... 20 more
All the information I've read suggests that this is caused by a conflict between different versions of JAXB. However, it doesn't seem that this is case for me. In the /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/ext folder I have jaxb-api.jar and jaxb-impl.jar. It doesn't seem that either of these appear more than once. Under "Referenced libraries" in the project, it doesn't seem like any other JAXB stuff is in there.
What am I missing?
EDIT: Here's a list of referenced libraries:

Infinite loop when deploying a war on tomcat 7

I try to deploy a war into Tomcat 7.0.29. I'm having the following log stack :
GRAVE: Error waiting for multi-thread deployment of context descriptors to complete
java.util.concurrent.ExecutionException: java.lang.StackOverflowError
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:574)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1413)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:313)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)
at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:346)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1140)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:785)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.StackOverflowError
at java.util.HashSet.<init>(HashSet.java:86)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2208)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2227)
(Many stack frames ommited...)
Does anybody face the same problem ?

This is reported upstream as issue #53871 in Tomcat. The problem appears to be with annotation scanning, and Tomcat 7.0.38 includes a clearer error message.
From the bug report:
Due to dependency management problems I deployed a WAR file containing two JAR files containing different versions of a library, where version 1 contained a class A which inherited from B and another version 2 which contained a class B inheriting from A.
The classes were loaded in such an order that A and B cyclically inherited from each other which leads to a stack overflow in populateSCIsForCacheEntry because it does not detect cycles in the inheritance tree.
This was exactly the problem in my case: an old version of dom4j bundled an incompatible version of jaxen. The new error diagnostic in 7.0.38 showed exactly which classes formed a loop and I fixed it by upgrading those dependencies.

I'm also encountering this issue in Tomcat 7.0.29 and Tomcat 7.0.30. However with Tomcat 7.0.28 everything works fine, so I suspect it's Tomcat issue, that was recently introduced.
The error encountered in 7.0.29 and 7.0.30, when starting Tomcat and deploying a war file:
14:01:06,380 ERROR [HostConfig:576] Error waiting for multi-thread deployment of context descriptors to complete java.util.concurrent.ExecutionException: java.lang.StackOverflowError
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)
at java.util.concurrent.FutureTask.get(FutureTask.java:111)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:574)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1413)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:313)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)
at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:346)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1140)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:785)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.StackOverflowError
at java.util.HashSet.<init>(HashSet.java:103)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2243)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2260)
at org.apache.catalina.startup.ContextConfig.populateSCIsForCacheEntry(ContextConfig.java:2260)

For me this behavior reproduced in IntelliJ Idea when I set the Application Context to the same name as the the Maven atrifactId in the .pom file.
E.g. my artifactId is 'test', then I set the Application Context (Edit configuration -> Tomcat Server -> Deployment, select the exploded artifact) to '/test'. As soon as I changed the Application Context, everything worked.

I had the same problem. I think it was caused by Tomcat 7, so when I changed to Tomcat 6.0.35, the problem resolved itself like a charm.

Use a lower version of Tomcat. There are problems with the version of Tomcat you are using.

A workaround : I changed the name of the WAR (no finalName in pom.xml and changed the artifact version) and it worked .... why? I don't know till now!
A real and a genuine solution? Definitely a new Tomcat Release . . .

docsplit/jodconverter openoffice issue on debian

I'm trying configure docsplit on a debian machine. After installing all of the dependencies I tried running a simple conversion form the command line to make sure it was working. I keep getting the following error with jodconverter:
Exception in thread "main" org.artofsolving.jodconverter.office.OfficeException: failed to start and connect
at org.artofsolving.jodconverter.office.ManagedOfficeProcess.startAndWait(ManagedOfficeProcess.java:64)
at org.artofsolving.jodconverter.office.PooledOfficeManager.start(PooledOfficeManager.java:101)
at org.artofsolving.jodconverter.office.ProcessPoolOfficeManager.start(ProcessPoolOfficeManager.java:62)
at org.artofsolving.jodconverter.cli.Convert.main(Convert.java:112)
Caused by: java.util.concurrent.ExecutionException: java.lang.NoSuchMethodError: method java.util.regex.Pattern.quote wit signature (Ljava.lang.String;)Ljava.lang.String; was not found.
at java.util.concurrent.FutureTask$Sync.innerGet(libgcj.so.90)
at java.util.concurrent.FutureTask.get(libgcj.so.90)
at org.artofsolving.jodconverter.office.ManagedOfficeProcess.startAndWait(ManagedOfficeProcess.java:62)
...3 more
Caused by: java.lang.NoSuchMethodError: method java.util.regex.Pattern.quote with signature (Ljava.lang.String;)Ljava.lan.String; was not found.
at org.artofsolving.jodconverter.process.LinuxProcessManager.findPid(LinuxProcessManager.java:51)
at org.artofsolving.jodconverter.office.OfficeProcess.start(OfficeProcess.java:65)
at org.artofsolving.jodconverter.office.OfficeProcess.start(OfficeProcess.java:60)
at org.artofsolving.jodconverter.office.ManagedOfficeProcess.doStartProcessAndConnect(ManagedOfficeProcess.java:119)
at org.artofsolving.jodconverter.office.ManagedOfficeProcess.access$000(ManagedOfficeProcess.java:31)
at org.artofsolving.jodconverter.office.ManagedOfficeProcess$1.run(ManagedOfficeProcess.java:58)
at java.util.concurrent.Executors$RunnableAdapter.call(libgcj.so.90)
at java.util.concurrent.FutureTask$Sync.innerRun(libgcj.so.90)
at java.util.concurrent.FutureTask.run(libgcj.so.90)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(libgcj.so.90)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(libgcj.so.90)
at java.lang.Thread.run(libgcj.so.90)
I've tried starting openoffice in headless mode with hte following
/usr/bin/soffice -headless -accept="socket,host=127.0.0.1,port=2002;urp"
EDIT:
I solved the above issue by removing my current OpenOffice installation and grabbing the most up to date packages from download.openoffice.org
I was sucessful in converting nd odt file to a pdf using the jodconverter jar that came with the docsplit gem, as follows:
java -jar /usr/lib/ruby/gems/1.8/gems/docsplit-0.6.3/vendor/jodconverter/jodconverter-core-3.0-beta-4.jar test.odt test.pdf
Unfortunately I'm still having an issue with docsplit. If I try to extract images from the odt file using docsplit at the command line as so:
docsplit images test.odt --format jpg
I get the following error from jodconverter:
Exception in thread "main" org.artofsolving.jodconverter.office.OfficeException: could not load document: test.odt
at org.artofsolving.jodconverter.AbstractConversionTask.loadDocument(AbstractConversionTask.java:92)
at org.artofsolving.jodconverter.AbstractConversionTask.execute(AbstractConversionTask.java:59)
at org.artofsolving.jodconverter.office.PooledOfficeManager$2.run(PooledOfficeManager.java:80)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.sun.star.lang.IllegalArgumentException: URL seems to be an unsupported one.
at com.sun.star.lib.uno.environments.remote.Job.remoteUnoRequestRaisedException(Job.java:177)
at com.sun.star.lib.uno.environments.remote.Job.execute(Job.java:143)
at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:335)
at com.sun.star.lib.uno.environments.remote.JobQueue.enter(JobQueue.java:304)
at com.sun.star.lib.uno.environments.remote.JavaThreadPool.enter(JavaThreadPool.java:91)
at com.sun.star.lib.uno.bridges.java_remote.java_remote_bridge.sendRequest(java_remote_bridge.java:639)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.request(ProxyFactory.java:151)
at com.sun.star.lib.uno.bridges.java_remote.ProxyFactory$Handler.invoke(ProxyFactory.java:133)
at $Proxy4.loadComponentFromURL(Unknown Source)
at org.artofsolving.jodconverter.AbstractConversionTask.loadDocument(AbstractConversionTask.java:90)
... 8 more
Any input would be appreciated.
-Thanks

The entire issue has been solved. I had originally installed jsut the openoffice.org meta package and the openoffice.org-headless package. I later noticed that the openoffice.org meta package did not install the individual components such as writer, calc, etc. After installing each of these packages I was able to run conversions using the docsplit command.