I want to move all gradle build folders to one another folder/structure outside project, is that possible?
I use Android Studio + Gradle. It’s android multi module project, so there is a bunch of build folders:
project/.gradle (optional to move)
project/build
project/module1/build
project/module2/build
project/module3/build
What I want to do is move all this (cache/temp) folders to different location outside of project.
I expected, that I will set buildDir=Z:/build/ in my global gradle.properties (and something in project based local.properties what will identify project) and it will create same structure as in project folder on my Z:/ drive inside build folder, but it didn’t and build failed.
I think, that it try to create all modules + main build folder inside one folder (all together and some files are rewritten by modules), so it fails to build.
What is my goal? Move all temp/cache files to different hard drive or ramdisk (for all project, because I work on more projects at ± same time). Reasons for it is 1) speed of storage (ramdisk in my case is 20x faster than my SSD in laptop) and 2) Lifetime of primary SSD. I don’t see a reason why I should use primary SSD for infinite writing of tons of temp files when it can be stored on some SSD/Ramdisk allocated just for builds/cache/temp files.
My goal is structure like:
Z:\build\projectX\build
Z:\build\projectX\module1\build
Z:\build\projectX\module2\build
Z:\build\projectY\build
Z:\build\projectY\module1\build
Z:\build\projectY\module2\build
In worst case share same folder:
Z:\build\build
Z:\build\module1\build
Z:\build\module2\build
Preferred to not modify build.gradle files, because it's shared between more devs and other devs will not want to do same local changes as me. Location of build folder I expect should be just local change (same as on CI we don't want to move this folders anywhere)
Same question on Gradle forum
EDIT1:
Using buildDir=Z\:/build/ in gradle.properties file in project can work, but only for monolitical projects without modules (only one app module), with modules it fails on Duplicating content roots detected
So, Z:\build\ contains content of /project/app/build/, when it's multimodule project it mixing content from all modules build folders into one same folder and breaks build.
I'm trying to move my IntelliJ IDEA (2017.3) Android project to another computer just copying the files and it does not work. I am aware of this and this, but in the case of Android project it does not work. All the xml files inside .idea store paths relative to the home ($USER_HOME$) instead of project home ($PROJECT_DIR$). Oddly, Maven projects seem to generate paths relative to the project home and those ones can be copied. But not with gradle projects.
Anyone knows how to solve this ?
EDIT: Bear in mind that I want to copy ALL project settings included running configurations. I want that someone opens the project and find exactly what I have. I know I can reimport the project, but then I'll loose some configuration.
Here's the files and folders that need to be excluded from the copy (assuming that your project has a module called app), preferably if you copy the entire project folder to some where else on the same computer and then deleting the unneeded one by one:
folders .idea, .gradle or any folder who's name starts with a .. They are usually found within the root folder of the project and within the module root folder.
build folder found in the project root folder and in module root folder.
any file who's extension is .iml, found in the project root folder and in module root folder.
local.properties found in project root folder.
The rest of the files and folders need to be kept. With the above excluded, the project can be re-imported in Android Studio properly with the correct configurations relative to your second PC.
On a side note, these are the typical exclusions added in .gitignore of an Android Project Git Repo.
Ok, I found the problem. It is related to how gradle resolve symlinks. This is the issue. Summarizing, if you open your project with a path that contains a symlink, absolute paths will be created in the configuration files and your project won't be portable.
I have reopened the project again using an absolute path and then all the configuration files use PROJECT_DIR instead of USER_HOME
I try to import my Android Studio project on different machines and wondering which project files are realy needed. For example the .idea or .gradle directories. I won't to much trash in my svn repo. Can someone tell my more about required files for Android Studio projects?
You need to keep these files in your root project
app folder (tough ignore the build folder inside it recursively, it's a big waste of space)
gradle
.gitignore if you are using GIT
build.gradle
gradle.properties if you want to have the same configuration on all of your pc's. You need to cinfugure it first tough.
gradlew
gradlew.bat
settings.gradle
Anything else that is not on the list and was not created by you, can be ignored
Make sure you ignore these by file name wildcard. This is the garbage created by macs and windows machines.
.DS_Store
desktop.ini
Thumbs.db
*.iml (garbage created by Android studio)
I truely recomend you to use git in Android Studio, the integration is awesome and it`s so easy to use. It select the files u need for you and have really good tools for merge files.
I saw a lot of examples for .gitignore files for AndroidStudio, some have .idea in them, and some don't.
Is there a good reason not to add the entire .idea dir to .gitignore?
If it should not be completely ignored, are there specific files inside .idea (such as .iml) that should be in .gitignore?
You can take a look at this page :
IntelliJ doc about project configuration files
In the "Directory-based format", a particular line is interesting :
The .idea directory contains a set of configuration files (.xml). Each file contains only a portion of configuration data pertaining to a certain functional area which is reflected in the name of a file, for example, compiler.xml, encodings.xml, modules.xml.
Almost all of the files contain information core to the project itself, such as names and locations of its component modules, compiler settings, etc. Thus, these files may (and should) be kept under version control.
However, I properly HATE to make project IDE-dependent (I am currently working on a project made with NetBeans and it hurts to use it with Eclipse which becomes the standard of my company).
So, to answer your question :
If you do not use something like Maven or Gradle to manage dependencies and build : keep the directory under version control. This way, the correct configuration of the project and dependencies will be available for everyone. In the counterpart, all developers will have to set their environment exactly the same way that you define it in the config files.
If you do use something like Maven or Gradle : correctly configure these tools and do not keep the directory under version control. Actually, all the information contained inside config files should be stored in Maven/Gradle files. Then let your developers configure their IDE depending of their environment. This way, using Eclipse, IntelliJ, Linux, Windows ... will not be a problem anymore.
OK, so after some "Yes" and "No" answers, I am adding a "Yes and no" answer :)
The problem is that .idea is used for both project build configuration (dependencies declaration) and project settings (inspections, etc.).
You definitely don't want to use your IDE for your build configuration, but you might want to share the settings among the team. That's why you need to ignore only a part of the .idea content (like the libraries folder and the modules.xml file), but keep others in the version control (e.g. the copyright, dictionaries and inspectionProfiles folders and files under .idea like dynamic.xml, codeStyleSettings.xml, etc.).
The concept of keeping the project configuration in VC is valid. I did this with my team because all of our developers happened to use PHPStorm for our projects and so it made sense to keep a common configuration ... in concept. We wanted to use the same dictionary files, the same coding standard rules, and the same plugin configurations.
The reason why I qualify this with "in concept" is because there were issues with JetBrains' .idea folder that led to us not being able to use it. These were probably issues that could have been avoided or fixed, but it was unclear to us how to do it right, and we think that's a fault of JetBrains because as developers we do not have time nor desire to search for solutions on how to make our IDE work correctly.
That being said, the issues were had are the following:
Symlinking project folders doesn't work right.
When I set up my projects, I symlink them into my home directory. What we discovered was that the project was set-up to use the exact symlink rather than just treating it like a concrete directory. This means that if another developer keeps his project in a different place, or simply does not use symlinks, the entire directory will be missing from the project navigator because it is quite literally looking for the symlink. What's worse is that I could never find this path value in the configuration. We were unable to find the exact config in the files constituting our .idea folder.
Definition files are partitioned to users by default. This means if I want to add a word to my dictionary, it will be listed as a definition for me, jgreathouse, but other users will have their own definition section. The flagged words will still show up as a spelling mistake for other users. This is not desireable. The reason I add it to my definition file is because the IDE is wrong. I want these definitions to be intuitively shared with other users.
Colleagues kept overwriting the configurations because their IDE would overwrite the configurations with their config currently in Memory. What I mean is that, a developer would be working, and merge their repository from origin, which would contain a project configuration change, instead of their IDE changing configurations, or even giving them a choice, it would automatically overwrite the .idea configuration with the current in-memory configuration of their IDE. In my opinion this makes the .idea configuration unusable as a shared configuration. In order to work around this, the developer would literally have to shut down that instance of their IDE, pull the repo, and re-open their IDE. It makes no sense to keep a shared configuration if the IDE instantly overwrites it with the configuration currently in memory. It's like not having a shared configuration at all.
I've done these types of shared IDE configurations in VC before with Visual Studio and Netbeans and it was always fine; but with .idea it feels simply unusable which is disappointing. I wish JetBrains would get on top of it and make it a better user experience.
As a complement to the explanations in this question GitHub's .gitignore template for Android includes the following files:
# IntelliJ
*.iml
.idea/workspace.xml
.idea/tasks.xml
.idea/gradle.xml
.idea/assetWizardSettings.xml
.idea/dictionaries
.idea/libraries
# Android Studio 3 in .gitignore file.
.idea/caches
.idea/modules.xml
# Comment next line if keeping position of elements in Navigation Editor is relevant for you
.idea/navEditor.xml
Notice also this entry from JetBrains guidelines on How to manage projects under Version Control Systems about sharing IDE project files with other developers:
What needs to be shared:
All files under the .idea directory in the project root except the
items that store user-specific settings: workspace.xml
usage.statistics.xml shelf directory
After switching to my release branch the project had a missing gen file so I added the gen file from java build path.
Now the assets and the res folders are show like gray packages and not folders and I get the errors like res/values/ is missing.
How to return to the standard android project structure in eclipse?
Is there a standard way of returning to the standard Android project. I have become tired to fix project properties and I have tried to clean and restart eclipse It seams that some project metadata is saved the wrong way.
Thanks .
/gen/ folder is automatically generated during compilation. You should include that and /bin/ and also /.properties/ to .gitignore to avoid having to fix properties all the time and also minimise the amount of unnecessary data stored in your repo.