Local Modules
This is a pattern followed by most Gradle projects where there is a library, then a sample app that uses that library - ref Gradle docs
- app/
- build.gradle
- src/main/java # where your main class would be
- library/
- build.gradle
- src/main/java # dependencies of the app module
- settings.gradle
- build.gradle
In that top-level settings.gradle
you have
include ':library', ':app'
And in the app/build.gradle
, you compile that included project
dependencies {
compile project(':library')
}
Basically, the top-level build.gradle
, is a wrapper for all common configs of the sub projects and variables. For example, it's most commonly used for a repositories { }
section for Maven urls, for example. Full details on that are at Gradle - Multi-project builds
Remotes Modules
The above is fine for working locally, but let's say you wanted to share your repo with many other developers without making them download extra source code. Then your would publish the other libraries to a remote server.
This is what you already doing when you add these lines to your project
implementation("org:artifact:version")
If your projects are public on GitHub, use a service like jitpack.io. You can also setup an account on Bintray OSS or Maven Central to have your libraries be available like most others.
If your projects are private within your company, you will need some Maven type server, whether that is a generic web server, or Nexus or Artifactory, you can add that with an addition to the repositories block.
repositories {
maven { url "http://some.maven.site/" }
}
Then add the compile
or implementation
sources, as normal
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…