I'm working in a project that has 3 modules as shown below:
Project
|
|-- Common
|
|-- SDK
|
|-- App
Common
is an Android library module that all the other modules depend on but I do not have to publish it anywhere because it contains only common code for the other modules. On the other hand SDK
is another Android library project which has to be published on our internal artifactory.
App
is a sample project of the SDK. I'm able to publish the SDK
artifact with no problems but when I import it in a client application the compilation fails because none of the classes from the Common
module are found.
For the third party dependencies that the SDK module depends on I use implementation
(e.g. implementation 'com.squareup.okhttp3:okhttp:3.11.0'
and all those dependencies are successfully added to the SDK
POM file) and for the dependency on the Common
module I use implementation project(path: ':Common')
.
In the client application that imports the SDK
library the compiler shows the following error
Error: cannot access Foo
class file for com.acme.Foo not found
(Foo is a class in the Common module)
Why when I import the SDK
none of the classes from the Common
module are found? What I expect is the compiler to merge the two modules into a single one. Has anyone an idea about how I can solve this problem?
(I know a solution is to publish Common
on the artifactory but I don't want to do that since this is only internal common code).
This is expected behaviour for gradle modules; as you surmised, publishing each as a separate artefact (and listing the dependencies in the pom file) is the only supported usage.
There is a plugin that may do what you need at https://github.com/adwiv/android-fat-aar , but it's no longer maintained so your mileage may vary. Alternatively, you may achieve similar results by updating your SDK sourceSets to point directly at the common module sources, and remove the gradle dependency entirely. Can't find a good link for this, but it should be possible. This does remove all the built-in handling of modules, but may better match how you're using the module.