Background story
I have this aar android library that developers can usually use with
compile 'com.companyname.sdk:android-sdk:2.x'
and now we are rewriting the library from scratch to create V3.
In this reorganization, we were able to break lib into modules. Thus, we can say that on V3 we would have the following artifacts
compile 'com.companyname.sdk:core:3.x' compile 'com.companyname.sdk:extra_1:3.x' compile 'com.companyname.sdk:extra_2:3.x' compile 'com.companyname.sdk:extra_ ....
and this would give the gradle structure the following modules:
root: |- test_app (apk just for testing, not deployed anywhere) |- sdk (aka: core) |- extra_1 |- extra_2 |- extra_ ... etc
for each extra module on their build.gradle there is a provided (':sdk') to use everything from the sdk module, but not actually compile it internally.
but I would also like to provide a simple migration path for existing host applications. Sense, I would like for V3 to also have the following artifact that combines core and extra_1 (which mainly relates to what is currently related to V2).
compile 'com.companyname.sdk:android-sdk:3.0.0'
This sounds great in theory, but it's very difficult for me to understand the gradle structure so that I can easily export all of these files.
What i want to achieve
Therefore, I would like to be able to generate the following artifacts during assembly:
android-sdk which includes both core and extra_1coreextra_1- ... all other additions
What i tried
add an additional module called legacy , apply com.android.library without code and add a compile project for both other modules. It generates an empty aar
add core / legacy buildTypes with source sets from both modules. 2 aar never generated
add core / legacy productFlavours using sourceSets from both modules. It does not compile because it cannot find the import from sdk that is declared in extra_1 (some of which are generated during the annotation processor or lombok)
add core / legacy productFlavours using compile project('extra_1') . It does not compile because there is a cyclic dependency between sdk and extra_1.
Answer
Based on Gabrielle's answer, I eventually figured out and found that the option of creating an add-on module with dependencies is correct. It will generate AARs with empty manifests and empty classes. But the important part is the POM file that it will generate, which will include the correct dependencies.
A caveat to the approach is to configure the maven-publish plugin. Usually you need a publishing object with publications and pom.withXml node. mine was as follows:
pom.withXml { def root = asNode() def license = root.appendNode('licenses').appendNode('license') license.appendNode('name', 'The Apache Software License, Version 2.0') license.appendNode('url', 'http://www.apache.org/licenses/LICENSE-2.0.txt') license.appendNode('distribution', 'repo') def dependenciesNode = asNode().appendNode('dependencies') configurations.compile.allDependencies.each { dependency -> def dependencyNode = dependenciesNode.appendNode('dependency') dependencyNode.appendNode('groupId', dependency.group) dependencyNode.appendNode('artifactId', dependency.name) dependencyNode.appendNode('version', dependency.version) } }
The problem with this approach is that dependency.version (at the end) is not specified, and as such it creates a POM file with <version>unspecified</version> .
The solution there is simple, replace the last with some u variable with a script with the correct version number. My looked like this:
dependencyNode.appendNode('version', "${rootProject.ext.SDK_VERSION}")