cannot run jenkins, even after clearing it's directory - java

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.

Related

java.lang.IllegalStateException: Session/EntityManager is closed only in uber-jar

I have an incredibly confusing error. I have several quarkus microservices, one of which runs a long process in a new thread where a database connection is also required (injected EntityManager). This used to cause an issue with the persistence context getting lost in the new thread, resulting in similar exceptions. We solved this by using a ManagedExecutor to run this new thread while conserving the persistence context. This works perfectly fine in development wie normal JARs or running the quarkus server with:
mvn quarkus:dev
However, for production we need to build a standalone uber-jar, which we do by building it with maven:
mvn package "-Dquarkus.package.type=uber-jar" "-DskipTests"
This works for all our quarkus services, and also generates one for this particular service. The server for it starts perfectly fine with the uber-jar, e.g. java -jar app-prod.jar, but when the beforementioned code with the new thread is executed, we suddenly get old familiar exceptions again:
java.lang.IllegalStateException: Session/EntityManager is closed
at org.hibernate.internal.AbstractSharedSessionContract.checkOpen(AbstractSharedSessionContract.java:407)
at org.hibernate.query.internal.AbstractProducedQuery.setHint(AbstractProducedQuery.java:1081)
at org.hibernate.query.internal.NativeQueryImpl.setHint(NativeQueryImpl.java:869)
at org.hibernate.query.internal.NativeQueryImpl.setHint(NativeQueryImpl.java:66)
at org.hibernate.internal.SessionImpl.applyQuerySettingsAndHints(SessionImpl.java:341)
at org.hibernate.internal.AbstractSharedSessionContract.getNativeQueryImplementor(AbstractSharedSessionContract.java:1143)
at org.hibernate.internal.AbstractSharedSessionContract.createNativeQuery(AbstractSharedSessionContract.java:1043)
at org.hibernate.internal.AbstractSharedSessionContract.createNativeQuery(AbstractSharedSessionContract.java:114)
at io.quarkus.hibernate.orm.runtime.session.TransactionScopedSession.createNativeQuery(TransactionScopedSession.java:413)
at org.hibernate.engine.spi.SessionLazyDelegator.createNativeQuery(SessionLazyDelegator.java:626)
at org.hibernate.engine.spi.SessionLazyDelegator.createNativeQuery(SessionLazyDelegator.java:65)
at org.hibernate.Session_5b93bee577ae2f8d76647de04cfab36afbf52958_Synthetic_ClientProxy.createNativeQuery(Unknown Source)
at com.test.webscraper.entity.repository.SourceTermRepository.getTotalAmountOfSourceTerms(SourceTermRepository.java:39)
at com.test.webscraper.entity.repository.SourceTermRepository_ClientProxy.getTotalAmountOfSourceTerms(Unknown Source)
at com.test.webscraper.bots.base.repository.TermRepositoryProxy.getTotalAmountOfSourceTerms(TermRepositoryProxy.java:92)
at com.test.webscraper.bots.base.repository.TermRepositoryProxy_ClientProxy.getTotalAmountOfSourceTerms(Unknown Source)
at com.test.webscraper.bots.base.JobRunner.initTermRepositoryProxyFor(JobRunner.java:99)
at com.test.webscraper.bots.base.JobRunner.tryToRunJob(JobRunner.java:82)
at com.test.webscraper.bots.base.JobRunner.runJob(JobRunner.java:70)
at com.test.webscraper.bots.base.JobRunner_ClientProxy.runJob(Unknown Source)
at com.test.webscraper.bots.base.async.JobRunnerThreadExecutor.lambda$executeJobRunFor$0(JobRunnerThreadExecutor.java:38)
at io.smallrye.context.impl.wrappers.SlowContextualRunnable.run(SlowContextualRunnable.java:19)
at io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:576)
at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1452)
at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:833)
We have no idea why this is happening (again) in the uber-jar version only. Can anyone clue me in on why this might possibly happen? Does something happen when a project gets packaged as an uber-jar particularly that may interfere with this?

Grails: Exception with RestBuilder only while running in production tomcat server

I created the war file and deployed into tomcat server but while submitting the registration page(having recaptcha) this error is happening, but not in the local machine and app running in the local machine using the GGTS IDE.
Following is the error happening in the production server
errors.GrailsExceptionResolver - ClassNotFoundException occurred when processing request: [POST] /IFP/signup/completeSignUp
grails.plugins.rest.client.RestBuilder. Stacktrace follows:
java.lang.ClassNotFoundException: grails.plugins.rest.client.RestBuilder
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.getDeclaredMethods(Class.java:1975)
at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46)
at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33)
at com.megatome.grails.recaptcha.ReCaptcha.checkAnswer(ReCaptcha.groovy:171)
at com.megatome.grails.RecaptchaService.verifyAnswer(RecaptchaService.groovy:147)
at com.controllers.portal.SignupController.completeSignUp(SignupController.groovy:42)
at grails.plugin.cache.web.filter.PageFragmentCachingFilter.doFilter(PageFragmentCachingFilter.java:198)
at grails.plugin.cache.web.filter.AbstractFilter.doFilter(AbstractFilter.java:63)
at grails.plugin.springsecurity.web.filter.GrailsAnonymousAuthenticationFilter.doFilter(GrailsAnonymousAuthenticationFilter.java:53)
at grails.plugin.springsecurity.web.authentication.RequestHolderAuthenticationFilter.doFilter(RequestHolderAuthenticationFilter.java:53)
at grails.plugin.springsecurity.web.authentication.logout.MutableLogoutFilter.doFilter(MutableLogoutFilter.java:62)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
From my view this exception is happening after the implementation of recaptcha.
Please help me for resolving this issue.
java.lang.ClassNotFoundException: grails.plugins.rest.client.RestBuilder
states clearly that this class is missing in your production war or Tomcat.
Make sure you are setting proper dependencies in your gradle config as per plugin ref-doc:
compile "org.grails.plugins:rest-client-builder:2.1.1"
Check that those jars are also present in your war or Tomcat's classpath
Copying the file grails-datastore-rest-client-3.1.4.RELEASE.jar into the tomcat lib folder resolved the problem.
You can download the jar file from here.
If someone is still looking for the answer: Please add the line below to build.gradle and it should work (pulls in a necessary dependency):
implementation 'org.grails:grails-datastore-rest-client:6.1.9.RELEASE'

Tomcat7 on Linux Server Not Connecting to MySQL DB [duplicate]

This question already has answers here:
Why am I getting a NoClassDefFoundError in Java?
(31 answers)
Closed last year.
I'm having an issue getting a servlet to connect to a MySQL database on Linux (Ubuntu) server running Tomcat 7.
I have the code running perfectly fine on the dev environment (Windows 7, Tomcat 7). I make the WAR file in Eclipse with mysql-connector-java-5.1.34-bin.jar in WEB-INT/lib directory then deploy on Tomcat / Linux environment.
The WAR file unpacks fine and the static content is served without issue to the browser but, when initiating a task to interact with the database, I get an error code 500 internal server error and the localhost.2015-03-24.log gives the following error:
java.lang.NoClassDefFoundError: javax/websocket/Endpoint
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2944)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1208)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1688)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1569)
at websocket.drawboard.DrawboardContextListener.contextDestroyed(DrawboardContextListener.java:32)
at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:5014)
at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5659)
at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1575)
at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1564)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
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)
Caused by: java.lang.ClassNotFoundException: javax.websocket.Endpoint
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1718)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1569)
... 17 more
I would also like to know how I can view the 17 other exceptions that are not being listed.
Make sure you set the WebSocketServlet dependency as provided.
<dependency>
<groupId>javax.websocket</groupId>
<artifactId>javax.websocket-api</artifactId>
<version>1.1</version>
<scope>provided</scope>
</dependency>
Thanks Arpit for your answer. However, adding the Maven dependenciy did not solve the problem. (On my Windows installation of Tomcat it worked all the time, on my Linux Tomcat not.)
As it turns out, the Debian (Ubuntu) version of Tomcat comes without the corresponding .jar (on Windows and normal Linux Tomcats it's included). Thus I tried adding the dependency with scope 'compile' to really add the .jar to my. war. No success either.
Finally the solution was to manually add the jars from the download of Tomcat from their website to Tomcat lib folder of the server.

Unable to start server due following issues: Launch process failed with exit code 1

For 3 days now, I have been trying to install glassfish 4.1 on eclipse Luna version 4.4.1. I first installed the plugin from eclipse marketplace then added it in my runtime using jdk 8. I also made jdk my default since eclipse default uses jre. I have to point out that I have been been using glassfish on netbeans and tomcat on eclipse but I decided to play around with glassfish on eclipse. Every information I got on the internet didn't fix my issue.
Below is the error I got in the console. Right now, this is driving me nuts so I have decided to come to you for direction.
Thanks
Launching GlassFish on Felix platform
ERROR: Unable to create cache directory: C:\Program Files\glassfish-4.1\glassfish\domains\domain1\osgi-cache\felix
ERROR: Error creating bundle cache. (java.lang.RuntimeException: Unable to create cache directory.)
java.lang.RuntimeException: Unable to create cache directory.
at org.apache.felix.framework.cache.BundleCache.<init>(BundleCache.java:131)
at org.apache.felix.framework.Felix.init(Felix.java:640)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiFrameworkLauncher$1.run(OSGiFrameworkLauncher.java:88)
Exception in thread "Thread-1" java.lang.RuntimeException: org.osgi.framework.BundleException: Error creating bundle cache.
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiFrameworkLauncher$1.run(OSGiFrameworkLauncher.java:90)
Caused by: org.osgi.framework.BundleException: Error creating bundle cache.
at org.apache.felix.framework.Felix.init(Felix.java:645)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiFrameworkLauncher$1.run(OSGiFrameworkLauncher.java:88)
Caused by: java.lang.RuntimeException: Unable to create cache directory.
at org.apache.felix.framework.cache.BundleCache.<init>(BundleCache.java:131)
at org.apache.felix.framework.Felix.init(Felix.java:640)
... 1 more
Exception in thread "main" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)
Caused by: org.glassfish.embeddable.GlassFishException: java.lang.NullPointerException
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:170)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)
... 6 more
Caused by: java.lang.NullPointerException
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.newFramework(OSGiGlassFishRuntimeBuilder.java:241)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.java:135)
... 9 more
Error stopping framework: java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:203)
Java HotSpot(TM) Client VM warning: ignoring option MaxPermSize=192m; support was removed in 8.0
Run Eclipse or any other IDE you use in Administrator mode.
Works for me.
I think your comment deserves to be posted as the main answer but I have been trying to mark your comment as answer but I wash't able to. So I decided to post post your comment here and then back it up with my own experience.
Answer by unwichtich:
I guess this is a similar problem. The cause may be that you have installed Glassfish in c:\Program Files. You can try to move your Glassfish installation to a directory where your normal user account has full access rights but you then have to change the path to the Glassfish installation in Eclipse.
My own experience:
Turns out that all the problems I had with the glassfish server (including exit code 1 error) was because glassfish could not handle folder names with spaces in it. So I moved the glassfish-4.1 folder from C:\Program File\glassfish-4.1.. path to C:\ glassfish-4.1.. It wiped all my tears away. This is really important in eclipse and netbeans IDEs (if you are installing the netbeans that does not come with a glassfish bundled zip).
I had the same problem and fixed it by installing Glassfish under C:\ instead of C:\Program Files. Try that.
use JDk 7 instead of JDK 8 am also faced the same issue i just changed to jdk7 its working now.

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

Categories