Feature Request P2
Status Update
No update yet.
Comments
da...@gmail.com
Note that I kept the gradlew and gradle directory because it is suggested to keep those in the versioning system
see:http://www.gradle.org/docs/current/userguide/gradle_wrapper.html
see:
sb...@google.com
sa...@dfarooq.com
Would be great if the `gradle` stuff was part of the Android SDK so it didn't have to be in the project at all.
da...@gmail.com
da...@gmail.com
To elaborate a little:
Android SDK provide a (two?) gradle plugins.
That should be enough, no need to tight gradle into the SDK in my opinion.
The wrapper works just perfectly and it is common practice in people using gradle to build their projects.
It takes very few kbytes in the VCS so I don't think it is a big deal ;)
my 2 cent
Android SDK provide a (two?) gradle plugins.
That should be enough, no need to tight gradle into the SDK in my opinion.
The wrapper works just perfectly and it is common practice in people using gradle to build their projects.
It takes very few kbytes in the VCS so I don't think it is a big deal ;)
my 2 cent
sb...@google.com
I'm not sure what
There's a good argument for shipping a version of Gradle and a version of the Android plugin with the SDK, namely so that developers can, out-of-the-box, create a project and build it without needing network access (otherwise the first thing the wrapper does when you do a build is download Gradle if needed and the plugin if needed). We're thinking hard about how to do this in a way that makes sense.
There's a good argument for shipping a version of Gradle and a version of the Android plugin with the SDK, namely so that developers can, out-of-the-box, create a project and build it without needing network access (otherwise the first thing the wrapper does when you do a build is download Gradle if needed and the plugin if needed). We're thinking hard about how to do this in a way that makes sense.
sa...@dfarooq.com
Hmm... I always thought it was basic CS principle that if something is common to millions of projects, it's best abstracted away, no matter how small but I guess the Gradle wrapper is considered more like build.xml (well, two build.xmls if you include the actual build file) than like ant, if you don't mind the analogy.
ol...@gmail.com
When you open a new project on Andorid Studio you now see 2 .gitignore files. Those are the solution: see also http://mauroolivo.com/android/gitignore-per-android-studio/
da...@gmail.com
To
the .gitignores provided in Android studio are hardly a good .gitignore for Android project.
The one I proposed is better: avoid versioning IDE specific files, which is bad practice (and they contain environment specific paths).
And it doesn't consider the NDK which I recently used (my git ignores now also contains ignores for NDK development)
the .gitignores provided in Android studio are hardly a good .gitignore for Android project.
The one I proposed is better: avoid versioning IDE specific files, which is bad practice (and they contain environment specific paths).
And it doesn't consider the NDK which I recently used (my git ignores now also contains ignores for NDK development)
sb...@google.com
jo...@google.com
jb...@google.com
ch...@google.com
ch...@google.com
kk...@google.com
da...@google.com
Presumably you want more than just C++ outputs included here, so the NDK isn't the right place to fix this.
Description
.gitignore for git
.hgignore for mercurial etc.
For example Android Studio create a lot of files that shouldn't be committed into the VCS (version control system).
Personally I use this .gitignore as a base:
# Android
gen/
build/
local.properties
.gradle/
# Old Android
bin/
# Idea
# According to this
# see
# I shouldn't ignore most of this stuff.. but looking at the content
# I see environment stuffs in it.
# And I don't see any particular advantage in having the idea stuff
# in my repo
# it would be helpful for code templates but it's simply not worth
# the effort currently
*.iws
*.iml
*.ipr
.idea
out
# Eclipse
.project
.classpath
.settings
# Mac
.DS_Store
# Generic
*~
.swp