Voltar história

Eu tenho essa biblioteca androidaar que os desenvolvedores podem usar normalmente com

compile 'com.companyname.sdk:android-sdk:2.x'

e agora estamos reescrevendo a biblioteca do zero para criar a V3.

Nesta reorganização, conseguimos dividir a lib em módulos. Pode-se dizer que na V3 teríamos os seguintes artefatos

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_ ....

e isso daria à estrutura gradle os seguintes módulos:

root:
  |- test_app (apk just for testing, not deployed anywhere)
  |- sdk (aka: core)
  |- extra_1
  |- extra_2
  |- extra_ ... etc

para cadaextra módulo em suabuild.gradle há umprovided (':sdk') para que possa usar tudo, desde osdk módulo, mas na verdade não o compila dentro de si.

mas também gostaria de fornecer um caminho de migração fácil para aplicativos host existentes. Ou seja, eu gostaria que a V3 também tivesse o seguinte artefato que combinacore eextra_1 (que é basicamente o que está atualmente na V2).

compile 'com.companyname.sdk:android-sdk:3.0.0'

Tudo isso soa muito bem na teoria, mas estou tendo muita dificuldade em descobrir uma estrutura gradle para me permitir exportar facilmente tudo isso.

O que eu quero alcançar

Então, eu gostaria de poder, durante uma construção, gerar os seguintes artefatos:

android-sdk isso inclui amboscore eextra_1coreextra_1... todos os outros extras

O que eu tentei

adicione um módulo extra chamadolegacy, Apliquecom.android.library sem nenhum código e adicionecompile project para os outros dois módulos. Gera um vazioaar

adicione buildTypes principais / herdados com o sourceSets de ambos os módulos. Nunca gerado 2aar

adicione produtos principais / herdadosFlavours com sourceSets de ambos os módulos. Não compila porque não consegue encontrar as importações desdk que são declarados emextra_1 (alguns dos quais são gerados durante o processador de anotações ou lombok)

adicionar produto principal / legadocompile project('extra_1'). Não compila porque existe uma dependência cíclica entre sdk e extra_1.

Responda

Com base na resposta de Gabrielle, acabei pesquisando mais e descobri que a opção de criar um módulo extra com as dependências é a correta. Ele irá gerar um AAR com manifesto vazio e classes vazias. Mas a parte importante é o arquivo POM que será gerado, que incluirá as dependências corretas.

Uma ressalva sobre a abordagem está na configuração domaven-publish plugar. Normalmente você precisa de umpublishing objeto compublications e umpom.withXml nó. o meu era o seguinte:

   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)
                }
            }

O problema dessa abordagem é quedependency.version (no final) não é especificado e, como tal, gera um arquivo POM com<version>unspecified</version>.

A solução é simples, substitua a última por alguma variável que você tenha no script pelo número da versão correta. O meu parecia:

dependencyNode.appendNode('version', "${rootProject.ext.SDK_VERSION}")