Gradle Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler()
up vote
15
down vote
favorite
I used gradle build command in Centos 7 terminal and I got output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler().
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
gradle
add a comment |
up vote
15
down vote
favorite
I used gradle build command in Centos 7 terminal and I got output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler().
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
gradle
1
Do you have appropriate privileges to run the command?
– Opal
Jun 15 '15 at 8:33
I think you are right, problem is with privileges, because in root user gradle work correctly, I try set 777 permissions to gradle folder using command chmod -R 777 ./gradle-2.4 ,but error still occur. Gradle folder I unziped in user home directory with which I get the error described above.
– Edgaras Karka
Jun 15 '15 at 10:12
Plonkingsudo
in front of the command I typed fixed this. The error message could be a bit more helpful in this regard.
– ben3000
Jun 29 '17 at 3:09
1
Worked for me when I killed gradle daemon.
– czesiek
Aug 16 '17 at 7:49
add a comment |
up vote
15
down vote
favorite
up vote
15
down vote
favorite
I used gradle build command in Centos 7 terminal and I got output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler().
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
gradle
I used gradle build command in Centos 7 terminal and I got output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler().
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
gradle
gradle
edited Nov 7 at 9:37
Vít Kotačka
420419
420419
asked Jun 15 '15 at 8:26
Edgaras Karka
2891215
2891215
1
Do you have appropriate privileges to run the command?
– Opal
Jun 15 '15 at 8:33
I think you are right, problem is with privileges, because in root user gradle work correctly, I try set 777 permissions to gradle folder using command chmod -R 777 ./gradle-2.4 ,but error still occur. Gradle folder I unziped in user home directory with which I get the error described above.
– Edgaras Karka
Jun 15 '15 at 10:12
Plonkingsudo
in front of the command I typed fixed this. The error message could be a bit more helpful in this regard.
– ben3000
Jun 29 '17 at 3:09
1
Worked for me when I killed gradle daemon.
– czesiek
Aug 16 '17 at 7:49
add a comment |
1
Do you have appropriate privileges to run the command?
– Opal
Jun 15 '15 at 8:33
I think you are right, problem is with privileges, because in root user gradle work correctly, I try set 777 permissions to gradle folder using command chmod -R 777 ./gradle-2.4 ,but error still occur. Gradle folder I unziped in user home directory with which I get the error described above.
– Edgaras Karka
Jun 15 '15 at 10:12
Plonkingsudo
in front of the command I typed fixed this. The error message could be a bit more helpful in this regard.
– ben3000
Jun 29 '17 at 3:09
1
Worked for me when I killed gradle daemon.
– czesiek
Aug 16 '17 at 7:49
1
1
Do you have appropriate privileges to run the command?
– Opal
Jun 15 '15 at 8:33
Do you have appropriate privileges to run the command?
– Opal
Jun 15 '15 at 8:33
I think you are right, problem is with privileges, because in root user gradle work correctly, I try set 777 permissions to gradle folder using command chmod -R 777 ./gradle-2.4 ,but error still occur. Gradle folder I unziped in user home directory with which I get the error described above.
– Edgaras Karka
Jun 15 '15 at 10:12
I think you are right, problem is with privileges, because in root user gradle work correctly, I try set 777 permissions to gradle folder using command chmod -R 777 ./gradle-2.4 ,but error still occur. Gradle folder I unziped in user home directory with which I get the error described above.
– Edgaras Karka
Jun 15 '15 at 10:12
Plonking
sudo
in front of the command I typed fixed this. The error message could be a bit more helpful in this regard.– ben3000
Jun 29 '17 at 3:09
Plonking
sudo
in front of the command I typed fixed this. The error message could be a bit more helpful in this regard.– ben3000
Jun 29 '17 at 3:09
1
1
Worked for me when I killed gradle daemon.
– czesiek
Aug 16 '17 at 7:49
Worked for me when I killed gradle daemon.
– czesiek
Aug 16 '17 at 7:49
add a comment |
9 Answers
9
active
oldest
votes
up vote
19
down vote
accepted
Try setting your GRADLE_USER_HOME
variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean
command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle
folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch
/mkdir
anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME
variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~
home directory (gradle_2_3_cache). This will help me in case I have another slave running on the same Slave machine but with different Gradle version for ex 2.5 etc version and if I want the .gradle
cache for 2.3 and 2.5/x version in separate folders.
Can you please explain it in more details. As I am also facing the issue. And I am a new Bee in Android.
– Pravinsingh Waghela
Nov 2 '17 at 13:20
add a comment |
up vote
9
down vote
For me, killing the Gradle daemon (gradle --stop
) really helped and fixed the issue.
1
Same here, my disk was full but even after making more room it still wouldn't work because the Gradle daemon didn't get the news for some reason.
– wkarl
Feb 15 at 9:21
add a comment |
up vote
4
down vote
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
add a comment |
up vote
3
down vote
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
add a comment |
up vote
2
down vote
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
add a comment |
up vote
1
down vote
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew
, gradlew.bat
and gradle/wrapper/*
) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
The whole point of the gradle wrapper, is to not depend on a gradle installation.
– Glenn Bech
Nov 2 at 10:13
For the end user, yes. However, you need to generate the wrapper files to deliver to that user. As a developer, it is prudent to check your Gradle installation is up-to-date before generating said files - especially if you are experiencing errors after upgrading your JDK.
– Flic
Nov 7 at 1:17
add a comment |
up vote
0
down vote
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
add a comment |
up vote
0
down vote
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME
did not work. I had to change the filesystem to be read/write.
add a comment |
up vote
0
down vote
Restarting the machine solved the issue.
add a comment |
protected by eyllanesc Jul 9 at 9:03
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
19
down vote
accepted
Try setting your GRADLE_USER_HOME
variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean
command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle
folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch
/mkdir
anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME
variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~
home directory (gradle_2_3_cache). This will help me in case I have another slave running on the same Slave machine but with different Gradle version for ex 2.5 etc version and if I want the .gradle
cache for 2.3 and 2.5/x version in separate folders.
Can you please explain it in more details. As I am also facing the issue. And I am a new Bee in Android.
– Pravinsingh Waghela
Nov 2 '17 at 13:20
add a comment |
up vote
19
down vote
accepted
Try setting your GRADLE_USER_HOME
variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean
command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle
folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch
/mkdir
anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME
variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~
home directory (gradle_2_3_cache). This will help me in case I have another slave running on the same Slave machine but with different Gradle version for ex 2.5 etc version and if I want the .gradle
cache for 2.3 and 2.5/x version in separate folders.
Can you please explain it in more details. As I am also facing the issue. And I am a new Bee in Android.
– Pravinsingh Waghela
Nov 2 '17 at 13:20
add a comment |
up vote
19
down vote
accepted
up vote
19
down vote
accepted
Try setting your GRADLE_USER_HOME
variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean
command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle
folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch
/mkdir
anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME
variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~
home directory (gradle_2_3_cache). This will help me in case I have another slave running on the same Slave machine but with different Gradle version for ex 2.5 etc version and if I want the .gradle
cache for 2.3 and 2.5/x version in separate folders.
Try setting your GRADLE_USER_HOME
variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean
command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle
folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch
/mkdir
anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME
variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~
home directory (gradle_2_3_cache). This will help me in case I have another slave running on the same Slave machine but with different Gradle version for ex 2.5 etc version and if I want the .gradle
cache for 2.3 and 2.5/x version in separate folders.
edited Nov 7 at 9:39
Vít Kotačka
420419
420419
answered Jul 17 '15 at 18:39
Arun Sangal
6,8632695173
6,8632695173
Can you please explain it in more details. As I am also facing the issue. And I am a new Bee in Android.
– Pravinsingh Waghela
Nov 2 '17 at 13:20
add a comment |
Can you please explain it in more details. As I am also facing the issue. And I am a new Bee in Android.
– Pravinsingh Waghela
Nov 2 '17 at 13:20
Can you please explain it in more details. As I am also facing the issue. And I am a new Bee in Android.
– Pravinsingh Waghela
Nov 2 '17 at 13:20
Can you please explain it in more details. As I am also facing the issue. And I am a new Bee in Android.
– Pravinsingh Waghela
Nov 2 '17 at 13:20
add a comment |
up vote
9
down vote
For me, killing the Gradle daemon (gradle --stop
) really helped and fixed the issue.
1
Same here, my disk was full but even after making more room it still wouldn't work because the Gradle daemon didn't get the news for some reason.
– wkarl
Feb 15 at 9:21
add a comment |
up vote
9
down vote
For me, killing the Gradle daemon (gradle --stop
) really helped and fixed the issue.
1
Same here, my disk was full but even after making more room it still wouldn't work because the Gradle daemon didn't get the news for some reason.
– wkarl
Feb 15 at 9:21
add a comment |
up vote
9
down vote
up vote
9
down vote
For me, killing the Gradle daemon (gradle --stop
) really helped and fixed the issue.
For me, killing the Gradle daemon (gradle --stop
) really helped and fixed the issue.
edited Aug 20 at 5:45
Pixel Elephant
11.5k33664
11.5k33664
answered Jan 26 at 14:20
Chiranjeevi
9112
9112
1
Same here, my disk was full but even after making more room it still wouldn't work because the Gradle daemon didn't get the news for some reason.
– wkarl
Feb 15 at 9:21
add a comment |
1
Same here, my disk was full but even after making more room it still wouldn't work because the Gradle daemon didn't get the news for some reason.
– wkarl
Feb 15 at 9:21
1
1
Same here, my disk was full but even after making more room it still wouldn't work because the Gradle daemon didn't get the news for some reason.
– wkarl
Feb 15 at 9:21
Same here, my disk was full but even after making more room it still wouldn't work because the Gradle daemon didn't get the news for some reason.
– wkarl
Feb 15 at 9:21
add a comment |
up vote
4
down vote
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
add a comment |
up vote
4
down vote
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
add a comment |
up vote
4
down vote
up vote
4
down vote
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
edited Jul 8 at 10:39
aioobe
319k75682742
319k75682742
answered Aug 26 '16 at 1:57
UnHee Schiefelbein
412
412
add a comment |
add a comment |
up vote
3
down vote
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
add a comment |
up vote
3
down vote
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
add a comment |
up vote
3
down vote
up vote
3
down vote
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
answered May 30 at 7:18
Zainub Wahid
314
314
add a comment |
add a comment |
up vote
2
down vote
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
add a comment |
up vote
2
down vote
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
add a comment |
up vote
2
down vote
up vote
2
down vote
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
answered Feb 8 at 12:45
Sergey Pavlov
1317
1317
add a comment |
add a comment |
up vote
1
down vote
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew
, gradlew.bat
and gradle/wrapper/*
) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
The whole point of the gradle wrapper, is to not depend on a gradle installation.
– Glenn Bech
Nov 2 at 10:13
For the end user, yes. However, you need to generate the wrapper files to deliver to that user. As a developer, it is prudent to check your Gradle installation is up-to-date before generating said files - especially if you are experiencing errors after upgrading your JDK.
– Flic
Nov 7 at 1:17
add a comment |
up vote
1
down vote
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew
, gradlew.bat
and gradle/wrapper/*
) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
The whole point of the gradle wrapper, is to not depend on a gradle installation.
– Glenn Bech
Nov 2 at 10:13
For the end user, yes. However, you need to generate the wrapper files to deliver to that user. As a developer, it is prudent to check your Gradle installation is up-to-date before generating said files - especially if you are experiencing errors after upgrading your JDK.
– Flic
Nov 7 at 1:17
add a comment |
up vote
1
down vote
up vote
1
down vote
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew
, gradlew.bat
and gradle/wrapper/*
) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew
, gradlew.bat
and gradle/wrapper/*
) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
answered Sep 26 at 5:07
Flic
526514
526514
The whole point of the gradle wrapper, is to not depend on a gradle installation.
– Glenn Bech
Nov 2 at 10:13
For the end user, yes. However, you need to generate the wrapper files to deliver to that user. As a developer, it is prudent to check your Gradle installation is up-to-date before generating said files - especially if you are experiencing errors after upgrading your JDK.
– Flic
Nov 7 at 1:17
add a comment |
The whole point of the gradle wrapper, is to not depend on a gradle installation.
– Glenn Bech
Nov 2 at 10:13
For the end user, yes. However, you need to generate the wrapper files to deliver to that user. As a developer, it is prudent to check your Gradle installation is up-to-date before generating said files - especially if you are experiencing errors after upgrading your JDK.
– Flic
Nov 7 at 1:17
The whole point of the gradle wrapper, is to not depend on a gradle installation.
– Glenn Bech
Nov 2 at 10:13
The whole point of the gradle wrapper, is to not depend on a gradle installation.
– Glenn Bech
Nov 2 at 10:13
For the end user, yes. However, you need to generate the wrapper files to deliver to that user. As a developer, it is prudent to check your Gradle installation is up-to-date before generating said files - especially if you are experiencing errors after upgrading your JDK.
– Flic
Nov 7 at 1:17
For the end user, yes. However, you need to generate the wrapper files to deliver to that user. As a developer, it is prudent to check your Gradle installation is up-to-date before generating said files - especially if you are experiencing errors after upgrading your JDK.
– Flic
Nov 7 at 1:17
add a comment |
up vote
0
down vote
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
add a comment |
up vote
0
down vote
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
add a comment |
up vote
0
down vote
up vote
0
down vote
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
answered Dec 26 '17 at 19:40
Rami Amr
416
416
add a comment |
add a comment |
up vote
0
down vote
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME
did not work. I had to change the filesystem to be read/write.
add a comment |
up vote
0
down vote
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME
did not work. I had to change the filesystem to be read/write.
add a comment |
up vote
0
down vote
up vote
0
down vote
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME
did not work. I had to change the filesystem to be read/write.
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME
did not work. I had to change the filesystem to be read/write.
answered Jul 9 at 8:58
antonagestam
2,23812032
2,23812032
add a comment |
add a comment |
up vote
0
down vote
Restarting the machine solved the issue.
add a comment |
up vote
0
down vote
Restarting the machine solved the issue.
add a comment |
up vote
0
down vote
up vote
0
down vote
Restarting the machine solved the issue.
Restarting the machine solved the issue.
answered Jul 12 at 20:31
YaBoiSandeep
688619
688619
add a comment |
add a comment |
protected by eyllanesc Jul 9 at 9:03
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
1
Do you have appropriate privileges to run the command?
– Opal
Jun 15 '15 at 8:33
I think you are right, problem is with privileges, because in root user gradle work correctly, I try set 777 permissions to gradle folder using command chmod -R 777 ./gradle-2.4 ,but error still occur. Gradle folder I unziped in user home directory with which I get the error described above.
– Edgaras Karka
Jun 15 '15 at 10:12
Plonking
sudo
in front of the command I typed fixed this. The error message could be a bit more helpful in this regard.– ben3000
Jun 29 '17 at 3:09
1
Worked for me when I killed gradle daemon.
– czesiek
Aug 16 '17 at 7:49