I have found 3 ways to define my project version.
In the documentation http://www.gradle.org/docs/current/userguide/dependency_management.html they talk to specify it in the manifest or the foldername (which already contains the project name).
Coming from a maven project I'm used to defining my version in my pom.xml and I have found project that also define their version in the gradle.build file in the version property
I'm looking for the correct way to handle my project version, so I can also depend on a certain version of my project.
The link that you have shared talks more about dependency management, and about good practises for versioning your artifacts.
There is a one-to-one relationship between a Project and a build.gradle file.
Also your build.gradle gives you a property:
version - The version of this project. Gradle always uses the toString() value of the version. The version defaults to unspecified.
This fits in for the project version.
You can set it directly in build.gradle, but depending on your use case you could pass it externally - using gradle.properties for example in multi-project builds.
You can also directly add properties to your project objects using properties files. You can place a gradle.properties file in the Gradle user home directory (defaults to USER_HOME/.gradle) or in your project directory. For multi-project builds you can place gradle.properties files in any subproject directory. The properties of the gradle.properties can be accessed via the project object. The properties file in the user's home directory has precedence over property files in the project directories.
Check for more details: http://www.gradle.org/docs/current/dsl/org.gradle.api.Project.html#org.gradle.api.Project:configurations%28groovy.lang.Closure%29
Add a gradle.properties file in the root directory of your project (same level as build.gradle) with this content:
version=0.0.1-SNAPSHOT
Related
I have a project structured as below.
parent
|---module1
|----pom.xml
|---module2
|----pom.xml
|---module3
|----src\main\java\source1
|----src\main\java\source2
|----src\main\java\source3
|----pom.xml
The issue here is intellij doesn't automatically recognize the sources under module3 and had to be defined explicitly under project setting > modules which is temporary and gets reset after every reimport.
Since intellij refers to standard <sourceDirectory> tag, I tried to put all sources under the tag but it accepts only single value.
Is there a way to configure the source folder under module3 on pom.xml so that maven and intellij both automatically recognizes the sources.
maven version I am using is apache-maven-3.6.0 and intellij version is
2020.2
I need do mention about Gradle to understand and find the same solution for Maven.
In Gradle exists the GRADLE_HOME and GRADLE_USER_HOME (repository) environment variables, for Maven the former through M2_HOME and about the repository I use the settings.xml file to define the <localRepository> location
For both Maven and Gradle I can define in peace the place about where is installed the software, for example other location than .m2 and .gradle to a secondary disk and even with customized directory names. Same goal about the repository location, both for a secondary disk (remember for Maven through the settings.xml file)
Note: therefore .gradle and .m2 are empty and not used.
In Gradle about the wrapper created, the gradle-wrapper.properties file has:
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-#.#.#-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
Then the final path is: GRADLE_USER_HOME/wrapper/dists
Therefore observe how GRADLE_USER_HOME (custom location - otherwise .gradle by default) is used to define the:
Local repository
Base path to install the downloaded Gradle through the wrapper
Goal: How accomplish the same behaviour for Maven? I mean, what should be the environment variable name (something like MAVEN_USER_HOME) for the local repository that Maven should recognize automatically? (not using the settings.xml file). It with the purpose to have any Maven wrapper installed according that environment variable name configured (custom location - otherwise .m2 by default) and of course defined the Local Repository too.
Therefore: I need the maven-wrapper.properties using something like MAVEN_USER_HOME (custom location - otherwise .m2 by default) according the developer/user in its machine.
For me, I am using spring boot boilerplate code that is generated from spring.io. Inside come with mvnw.cmd. By setting MAVEN_USER_HOME to a customized location, running mvnw.cmd will download the maven to that customized location.
Once done, I still need to manually go to that downloaded maven location to configure the settings.xml to point to a customized location for the maven libraries repo.
So at the moment, sadly, seem like the settings.xml is required to configure the repo, and MAVEN_USER_HOME environment variable has nothing to do with the repo.
I have installed gradle with chocolatey package manager, but in .gradle directory there is no gradle.properties file. Do I need to re-install gradle? or what should I write besides what I need to add in grdle.properties file If I will create it?
P.S: I use gradle plugin in Spring Tool Suite, and I need to add something in the gradle.properties file concerning the project
The propery file gradle.properties is not created automatically during Gradle installation. You can create this file manually and add your specific configuration into it. Note that there are two places where you can create a gradle.properties file, as described in documentation Gradle configuration properties
We are using gradle wrapper for our project
There is a gradle-wrapper.properties generated as part of the wrapper
We would like to know whether the gradle-wrapper.properties in the wrapper will over ride the gradle.properties available in the user home directory.
For eg: if Developer has a different gradle installation and has a gradle.properties in his machine, and when we enforce gradle wrapper, we observed that the local gradle.properties is considered for build.
Is this the expected behavior?
No, the gradle properties file specifies the properties to be used by gradlew script, like what version to download and use, and not properties for the build process.
Moreover, the gradle.properties file should be shipped along with your source code.
In a normal project, I can have a structure like this:
myProject/
build.gradle
gradle.properties
**settings.gradle**
but if I have another project
myProject2/
build.gradle
gradle.properties
it works fine.
Things go strange when myProject2 is a subfolder (but not sub-project) of myProject.
myProject/
myProject2/
build.gradle
gradle.properties
build.gradle
gradle.properties
settings.gradle
How does gradle find what settings file to use?
The settings.gradle file has the next 2 main purposes:
Add libraries to your build script classpath
Define which projects are taking part in the multi-project build
Therefore it is optional for a single-project build but due to #2 it is mandatory for multi-project builds.
By default it is assumed that the location of the settings file is also the location of the root project but you can redefine the location of the root project in the settings file.
Now, gradle logic for locating settings.gradle file as documented in gradle user guide here:
If you trigger a multiproject build from a directory with a settings
file, things are easy [Amnon - you just found it]...
If you execute Gradle from within a project with no settings.gradle file, Gradle looks for a settings.gradle file in the following way:
It looks in a directory called master which has the same nesting level
as the current dir.
If not found yet, it searches parent directories.
If not found yet, the build is executed as a single project build. If
a settings.gradle file is found, Gradle checks if the current project
is part of the multiproject hierarchy defined in the found
settings.gradle file.
If not, the build is executed as a single
project build. Otherwise a multiproject build is executed. Otherwise
(you executed Gradle from
(Gradle user guide also provides the purpose of this behavior here).
Now, back to your case, the first two project layouts you provided are for a single project build so settings.gradle is optional. For your third project layout if you'll run gradle from the root project (myProject) then it will find settings.gradle next to it but if you'll run it from myProject2 folder then since this project parent path contains a settings.gradle file, gradle will find it and use it.