In my project I have settings.gradle, gradle.properties and gradle-wrapper.properties files. Which of them should be checked in a Git repository?
All of those files should be commited as they all contain information critical to the build environment for the project.
The one exception would be if you needed to create a local.properties file to override or supplement those files on your computer specifically. The Configure your build section of Android Developer site has more information.
Additionally, when in doubt a good rule of thumb is to use a tool like gitignore.io to generate a Git gitignore file. It generally contains sane default rules on which files should be excluded from source control (and thus included).
Better to check all of them
settings.gradle --> This contains information which module should you include and the structure of project. Some plugin like gradle build scan also need to specify here.
gradle.properties --> Sometimes you want to specify JVM arg here, also some flag from android gradle plugin features, for example incremental build, kapt features, gradle flag feature (like configuration cache) etc.
gradle-wrapper.properties is defined gradle version used in your project. Some plugin may not compatible with other gradle version, so you should check it too in order to make sure everyone using the same version.
Related
I use them often when configuring my project but mostly add snippers as instructed. I have absolutely no clue which file is for what exactly. Can anyone give a clear picture what each file is for.
So far I think
local.properties for environment paths like sdk/ndk location
settings.gradle for including all modules in project where each module has it's own build.gradle
gradle.properties ?
gradle-wrapper.properties ?
gradle.properties
Using gradle.properties to create universal variables
This solution is limited to Android projects as far as I know. In /gradle.properties you can define your universal or project level variables as such: Link
myBuildToolsVersion=20.0.0
myMinSdkVersion=10
myTargetSdkVersion=22
myCompileSdkVersion=22
gradle-wrapper.properties
Internally, Android Studio uses the version of Gradle that is defined in the wrapper configuration. That configuration can be found in gradle/wrapper/gradle-wrapper.properties. When Google decides that it is time to use a new version of Gradle, Android Studio will display a message nudging you to upgrade. All you need to do then is click the message and Android Studio will edit the properties file and synchronize the Gradle installation for you. Link
local.properties
The local.properties file goes in the project's root level.
This file should not be included in source control. After (incorrectly) including this in source control, then deleting the file locally, Android Studio re-created the file for me automatically.
Here is the example content of this file:
## This file is automatically generated by Android Studio.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must *NOT* be checked into Version Control Systems,
# as it contains information specific to your local configuration.
#
# Location of the SDK. This is only used by Gradle.
# For customization when using a Version Control System, please read the
# header note.
#Thu Aug 14 14:49:26 PDT 2014
sdk.dir=C\:\\Program Files (x86)\\Android\\android-studio\\sdk
Note the sdk.dir= reference to the location of the Android Studio SDK installation (which may be different on different machines).
Link
settings.gradle
':lib' is a logical project path, which gets mapped to a physical path based on information provided in settings.gradle.
A multi-project build can have an arbitrary directory structure, which is configured in settings.gradle. No need to move directories around, unless you want to. Link
For more and more info about gradle you need to check below links which help you more know about gradle and gradle system. Gradle makes developer life easy for not taking to much headache about library updation , apk generation , import lib easily , product flavors and many more.
http://www.vogella.com/tutorials/Gradle/article.html
https://developer.android.com/studio/build/gradle-tips.html
Gradle includes two properties files, located in your root project directory, that you can use to specify settings for the Gradle build toolkit itself:
gradle.properties
This is where you can configure project-wide Gradle settings, such as the Gradle daemon's maximum heap size.
local.properties
Configures local environment properties for the build system, such as the path to the SDK installation. Because the content of this file is automatically generated by Android Studio and is specific to the local developer environment, you should not modify this file manually or check it into your version control system.
I created a new project in Android studio and got many files generated, where as my actual code is found in just one folder - src.
Why the so complicated structure? Please explain the motivation of putting meta-files at the root of the project instead of some inner folder named gradle.
Android build system consists of an Android plugin for Gradle. Gradle
is an advanced build toolkit that manages dependencies and allows you
to define custom build logic. Android Studio uses a Gradle wrapper to
fully integrate the Android plugin for Gradle.
Android Studio projects contain a top-level build file and a build file for each module. The build files are called build.gradle, and they are plain text files that use Groovy syntax to configure the build with the elements provided by the Android plugin for Gradle.
Gradle is an automated build toolkit that allows the way in which projects are built to be configured and managed through a set of build configuration files. This includes defining how a project is to be built, what dependencies need to be fulfilled for the project to build successfully and what the end result (or results) of the build process should be. The strength of Gradle lies in the flexibility that it provides to the developer.
For more info you may visit
Gradle Tutorial
Android Application Modules
First of all if you don't want to see those metadata... you can change it(see Image)..
gradle is required to compile your project. for example: In gradle file we specify minsdk version,maxsdk version and dependencies etc
To Know more about gradle go to http://gradle.org/the-new-gradle-android-build-system/
Why the so complicated structure?
IMHO the structure you are referring to is pretty straightforward but your assumption that all those meta-files are related with gradle is wrong.
Meta-files related with your android application are located inside the "app" sub-folder. You have some gradle files there because those are for the purpose of building that specific module.
As pointed out before in a previous answer the best resource to understand the file tree structure for this part is here.
You also have some metadata generated by the IDE (.idea sub-folder):
IntelliJ IDEA stores the configuration data for projects and their
components in plain text XML files making it easy to manage and share
project configuration data with others.
And .iml files:
A module is a discrete unit of functionality which you can compile,
run, test and debug independently.
Modules contain everything that is required for their specific tasks:
source code, build scripts, unit tests, deployment descriptors, and
documentation. However, modules exist and are functional only in the
context of a project.
Configuration information for a module is stored in a .iml module
file. By default, such a file is located in the module's content root
folder.
More info about can be found here.
Please explain the motivation of putting meta-files at the root of the
project instead of some inner folder named gradle.
As mentioned before in some previous answers some metadata is related with the configuration of your project itself and some is module-specific. One example is the build.gradle files. The global file has this comment:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
About the motivation I only assume it was for simplicity and to keep the semantics of the project structure. Other possibility is that it was just by convention.
I created a test project to understand how to build and run the tests using command line tool. I managed to create a project, updated it with
android update project -p .
and debug with
ant debug
When I added a library project to this test project, the ant debug started to fail because it couldn't find the build.xml of the library. The only solution I found atm is to update the library project as well (found here). Is this the correct way? I see pom.xml files in many of the libraries that I use. I know it is used by Maven (although I know nothing about it) and it might help me with another solution.
Ant is the official way to build android apk. Maven is an alternative way of doing it (not officially supported, but it works very well).
There are few differences regarding default project layout when working with maven or ant, but it's possible to have both build system working on the same source code if you do some additionnal configuration work (i.e. some information will be duplicated).
Default project layout with maven
java source files are under `/src/main/java``
dependencies are defined in the pom.xml (using the maven way of defining dependencies, with type apklib for android libraries)
Default project layout with ant (and eclipse ADT plugin)
java source files are under /src
dependencies are defined in /project.properties and are specified using relative path.
Here is an example of project.properties (it's a typical example of a library project referencing 2 other library project):
target=android-15
android.library=true
android.library.reference.1=../somelib
android.library.reference.2=../someOtherLib
(as you can see some additionnal information are stored in this file : the android target and the fact that the project is an library or an app. When you use maven, this information is in the pom.xml)
How to build a maven android lib with ant ?
The problems (when you need to build a maven-layout-android-library with ant) are the following:
having a proper /build.xml (it can be done through android update library-project ... here is the official doc about this command)
having a proper /project.properties (it is partially done by the android update ... command, but you may need to add some android.library.reference by hand or with eclipse ADT plugin)
telling ant that the java source files aren't at the default location, but are under /src/main/java
For this last point, here is how to do it:
create a file /ant.properties (in your maven-layout-android-library)
put the following entry in it:
source.dir=src/main/java
(Important : it is not always required because sometimes the java source files are already under /src in the maven-layout-project and in this case, the pom.xml contains the information that the source dir is /src)
And that's all. Now, your maven-layout-android-library can be build with ant debug
I'm using ActionBarSherlock as a library. We haven't included ABS into our repository so everyone participating our project must download and install it separately. ActioBarSherlock is an Android library project and I have got it running by opening it and my project in the same Eclipse's workspace (neither of those are copied into workspace, they both exists in another folder) and adding it into my project.properties by following this:
Referencing a library project.
That reference path is relative and since everyone might have ABS in different folder, we also have different paths in Eclipse's project.properties file as android.library.reference.1. Is there any way locally override that library path so that we can have project.properties in our repo but Eclipse will use locally some other path? Currently I have to manually fix that path after every time I pull from our repo because of different paths.
There exists other *.properties files but Eclipse ignores them:
local.properties
Customizable computer-specific properties for the build system. If you use Ant to build the project, this contains the path to the SDK installation. Because the content of the file is specific to the local installation of the SDK, the local.properties should not be maintained in a source revision control system. If you use Eclipse, this file is not used.
ant.properties
Customizable properties for the build system. You can edit this file to override default build settings used by Ant and also provide the location of your keystore and key alias so that the build tools can sign your application when building in release mode. This file is integral to the project, so maintain it in a source revision control system. If you use Eclipse, this file is not used.
Just have each person put it in projectroot/libs. The newer (ADT 17 and above, IIRC) versions of the ADT will automatically pick it up and compile it into your app. Note that the folder is libs, with an s, and not lib. Using /lib won't work.
Options:
project.properties: You could create a link in every users home folder, libs and have the path in the project.properties refer to ~/libs
Using a common library:
Create a library project called "common". In settings, have it export the jar. In your Android application, import the jar.
Personally I think configuring with maven would be best but the 2nd option was quickest.
What about if you ignore the project.properties in your repo? That way each user can keep their own and you won't need to override it all the time. I don't think you can override that locally.
Another option to simplify things is you can export the project as a JAR file instead of referencing it as a library project. If you don't need to modify ABS code you can right click the project -> java -> jar file and all the developers can keep that in the same place for the sake of simplicity.
Edit: This question is no longer needed for our project since we moved from Eclipse to Android Studio and Gradle build system. Eclipse with Maven should have worked too, as #bgs suggested.
Our previous approach:
Still looking for better alternative but so far we ended up keeping project.properties in our repo. project.properties does not get overridden if there is no changes to it when pulling. We also suggest in our README that users add this
[alias]
commit = commit -X project.properties
to their .hg/hgrc configuration file to prevent accidentally commiting changes of that file.
This method has at least one drawback: When merging, you might get error like this abort: cannot partially commit a merge (do not specify files or patterns) even when you commit your merge with hg commit -m 'merge'. If this happens, disable that alias temporarily.
I'm working on an existing project from my wd of git.
.classpath and default.properties files are on the repository.
When I import the project to Eclipse, my default.properties is replaced by a project.properties (the files' contents are the same) and my .classpath is modified.
As I said, these files are on the repository, so my git status is never clean.
Do you know how to force Eclipse using the files provided on the repository without modifying them ?
Thanks
default.properties (or project.properties)
Check out the changelog of SDK r14 release:
default.properties which is the main project’s properties file containing information such as the build platform target and the library dependencies has been renamed project.properties
If someone from your development team still use a version older than r14, better to ask them upgrade to latest Android SDK version on their workstation, as the Android SDK has been changed rapidly since r14 regarding to project property file, library project, external jar dependency structure and etc. It will make development very hard to maintain if developers use different Android SDK version in a team.
If this is not an option in a short term, you should temporarily create and check-in both default.properties and project.properties (with the same contents) for a short period of time, to support old Android version in a short term and give other people time to upgrade their workstation.
.classpath
It is a very bad practice to commit IDE generated files (.classpath, .project and etc.) into source control. Do you expect .classpath generated from a Windows box has exact the same contents as the one generated from a Mac box? You should add .classpath to your source control ignore list so that it is ignored automatically whenever you commit your project to source control.
When use a source control system, Don't consider too much for every single commit, as long as you provide fully detailed comments. as every single action (add, modified, deleted and etc.) you did on every single file (java source, properties and resources file and etc.) in your project are logged and tracked in source control, in case if something goes wrong, it is quite easy for a sophisticated developer to track the change and revert the project into a normal state. Hope this helps.