I have a project with a buildSrc that has a package (eg abc).
I use that package in my other project build.gradle files (eg abc.test()). Given that it's under buildSrc, it is imported automatically, and it's been working on my macbook.
I am now trying to do the same thing with windows + WSL.
My current setup involves having java and gradle installed in windows (and working via Android Studio), while also having java and gradle installed in WSL. The short story is that WSL's gradle kept complaining about bad java_home paths when they were shared, so I installed everything as if it were pure linux.
When trying to run gradle build, the command now complains:
> Could not get unknown property 'abc' for object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
Is there a way around this? Is there a better workaround to running gradle tasks from WSL? I'm using this in a pre-commit, so I'm even open to having it run the command "through windows" if it helps. As of now, I suspect it's a pathing issue, because build commands work fine in the IDE.
Related
I have different version for command gradlew --version and gradle wrapper --version, why is that?
Gradlew vs Gradle Wrapper
They are two different executables. gradle is the one installed globally and located in your path. Adding the option wrapper to the gradle command did not change anything for it and you are just seeing the output of gradle --version.
gradlew is the wrapper version installed in the current folder. This version can be different to the gradle one.
A user of my repo did not need to install gradle at all, when I add the wrapper directly to the root folder.
And even if you have a newer version, my project still works with the version I tested it with. So it is quit common the gradlew version is different to your gradle version.
You can update the gradlew version with the wrapper option and you can also use the gradlew wrapper command so the wrapper updates itself.
When you are using linux you can check with which gradle, which gradlew where the exeutables are located (or where gradle for a Windows CMD).
More infos can be found in the offcial documentation:
https://docs.gradle.org/current/userguide/gradle_wrapper.html
I'm working on a Gradle project with multiple sub modules. Some of these are using maven. Thus one Gradle task is running maven from the MAVEN_HOME directory. This task is called by IntelliJ IDEA during Gradle refresh. When running IntelliJ Community Edition 2021.1 on an Ubuntu 20_05 VM, everything works fine. When running the same version of IntelliJ Windows with WSL 2, the task fails with error
MAVEN_HOME environment variable not set, unable to locate mvn executable for build
When I open a shell in WSL, I see that the MAVEN_HOME is actually set. I've defined it in my ~/.profile file. I can build my project from the terminal command line. IntelliJ IDEA uses the Gradle wrapper for building the project. It uses the shebang #!/bin/env sh. So it is not opening a login shell und thus the ~/.profile files are not read.
Any ideas how to solve this problem?
I am trying to update my local gradle(out of ide) from 6.5.1 to 7.0.0.
I try two commands from gradle website and network in cmd and path is the root of one of my project(there are gradlew.bat and gradlew files):
gradle wrapper --gradle-version=7.0 --distribution-type=all
gradlew wrapper --gradle-version=7.0 --distribution-type all
And, i try those commands to check the version
gradle -v
gradlew -v
The gradlew updates sucessfully. It prints version 7.0.0.
However, the version of gradle is still in v6.5.1.
How can I update it without download the v7.0.0 packet and cover the files in disk(I am worrying about that i should download all of my packages again in new gradle)?
ps: the gradle is locating in D:\gradle in my disk and java environment is openJDK 15
Thanks agains
I had the same problem and, in my case, the problem was a running gradle demon using the previous version. Check running demons with:
gradle --status
Stop the demons with
gradle --stop
Also I restarted the console/terminal.
You cannot update your gradle standalone version without downloading it, and with gradle wrapper you cannot upgrade your gradle installation, it always works on your current project folder (command gradlew) only. To upgrade a standalone gradle installation (command gradle without the wrapper prefix w), you have to manually download the binaries, include the new bin directory in your PATH environment as described in the manual on the gradle homepage, or use a package manager like sdk man, chocolatey, brew etc.
If you are using the gradle wrapper gradlew for your builds, it works completely independent from your gradle installation.
I'm learning gradle and some questions bother me
When I want to use gradle, I'd better use gradlew. But when I want to use gradlew, I need a installed gradle. So is that a story about chicken and egg?
Should be gradle-wrapper.jar uploaded to git repository? Some docs say git should track it, but it seems not good to track a binary file with git.
Using ./gradlew you are using a gradle wrapper. The wrapper is part of a project and it is able to download and install a specific version of gradle.
The Gradle Wrapper consists of a few files in your project directory:
gradlew: The shell script Unix users can run to execute Gradle tasks
gradlew.bat The bat script Windows users can run to execute Gradle tasks
gradle/wrapper/gradle-wrapper.jar The wrapper’s executable JAR; this is where the wrapper code resides
gradle/wrapper/gradle-wrapper.properties A properties file for configuring the wrapper
Using the wrapper guarantees that every developer on your team in a specified project is using the same version of Gradle and that they can run Gradle builds.
You should make sure all these are committed to version control
You can easily change the version of gradle used in the project just changing the gradle/wrapper/gradle-wrapper.properties file with the distributionUrl properties. For example:
distributionUrl=https\://services.gradle.org/distributions/gradle-4.0-all.zip
You can find more info about the wrapper here.
Using ./gradle you need to download and install manually the gradle version before.
It means that every developer in a team can use different version on the same project.
Can not get the terminal commands to work with gradle. I am trying to get Gradle to work outside of Android Studio as a prelude to scripting up various flavors of my app. I got the flavors to build within Android Studio but I find the interface confusing.
Gradle was installed either with ADT or Android Studio at: /home/mark/.gradle
Would like to use the install of Gradle at /home/mark/.gradle. Would like to avoid the Gradle in the repo since Android Studio updates frequently and their a possibility that I could wind up with two different versions of Gradle that could cause more headaches.
So far I have tried setting the PATH various ways in .bashrc bash.bashrc environment
files. Nothing worked.
Not sure if I put the wrong terms/commands in those files or the files are wrong ones. Tried the gradle term with and with out the dot as well. I would appreciate explicit instructions on terms/commands and in what files.
The gradle executable is usually installed here (when installed by by android-studio):
<user_home>/.gradle/wrapper/dists/gradle-<version>-bin/<some_key>/gradle-<version>/bin/
So be sure that your PATH variable include this path.
Alternativelly, you can download the gradle distribution, unzipping it in a more convenient location and use that location in your PATH.
Wathever your choice is (i.e. using the gradle installed by Android-Studio or download and install a distribution of gradle yourself) : you have to take care to maintain your PATH variable up-to-date when you install a newer version of Android-Studio.