I'm trying to migrate my applications to use gradle, but I'm facing some problems including library projects.
My project tree is this:
My projects root
- MyLib1
-- res
-- src
-- libs
- MyLib2
-- res
-- src
-- libs
- MyLib3
-- res
-- src
-- libs
- MyAppBase
-- res
-- src
-- libs
- MyApp - full version
-- res
-- src
-- libs
- MyAppFree - free version
-- res
-- src
-- libs
With Eclipse I had the following dependencies
MyAppBase depends on:
-MyLib1
-MyLib2
-MyLib3
MyApp depends on:
-MyAppBase
-MyLib1
-MyLib2
-MyLib3
MyAppFree depends on:
-MyAppBase
-MyLib1
-MyLib2
-MyLib3
This organization worked well within Eclipse, but now with Android-Studio and gradle I'm having problems.
I've got the following build.gradle file:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.7.+'
}
}
apply plugin: 'android'
dependencies {
//compile project('../MyLib1') <- error
compile fileTree(dir: 'libs', include: '*.jar')
}
android {
compileSdkVersion 18
buildToolsVersion "19.0.1"
defaultConfig {
minSdkVersion 4
targetSdkVersion 14
}
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
}
// Move the tests to tests/java, tests/res, etc...
instrumentTest.setRoot('tests')
// Move the build types to build-types/<type>
// For instance, build-types/debug/java, build-types/debug/AndroidManifest.xml, ...
// This moves them out of them default location under src/<type>/... which would
// conflict with src/ being used by the main source set.
// Adding new build types or product flavors should be accompanied
// by a similar customization.
debug.setRoot('build-types/debug')
release.setRoot('build-types/release')
}
}
How can I include the projects MyLib1, MyLib2, MyLib3 as a dependency so It will be compiled along with my project???
At present, all dependencies need to live under the project's root directory, so you'd need to set up your project to be rooted at the directory above MyLib1, MyLib2, MyApp, etc. This limitation will be lifted in the future; you can track its progress at https://code.google.com/p/android/issues/detail?id=56367. Your libraries would be library modules under that root, and your app(s) would be Android application modules. Each module has its own separate build.gradle file and can compile to a JAR (plain Java library), AAR (Android library, which includes code + resources), or APK (Android app).
I'm not sure if MyAppFree and MyApp are separate Eclipse projects; if they are, under Android Studio and Gradle I'd encourage you to combine them into one module that has free and paid flavors. Build flavors are designed explicitly to aid this sort of use case. See http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-flavors for more info.
UPDATE
In the comments below it looks like you have a very large number of libraries. In that you probably don't want to build them all from source all the time, or manage a project that has dozens of modules. In that scenario, keeping modules that don't change very often as separate projects makes more sense. Those projects can compile to JAR or AAR, which brings us back to your original question of how to make those work in Android Studio.
You could copy JAR files into a libs directory under your project root and link them in. I believe there are problems trying to do the same with AAR libraries; see https://code.google.com/p/android/issues/detail?id=63908 to track the progress of that. If you don't want to maintain multiple copies of the libraries, you could either try symlinking the directories (I think that will work), or you could set up a local Maven repository and have the side projects publish their artifacts to that. I don't have links with detailed instructions on that at my fingertips; you could start with http://www.gradle.org/docs/current/userguide/publishing_maven.html.
There will be a fair learning curve to getting a local Maven repo set up, but once it's done, you'll probably find that it solves your problem pretty cleanly, and if you're in a shop with multiple developers and would like an organization-wide Maven repo, perhaps with artifacts that are published to it from a build server, you can set that up.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With