I have a project with multiple modules (gradle modules) and some are depend on some others, for example :modules:backend:core has a project dependency on :modules:libraries:util:core and some others.
In my gitlab CI job I am able to tell when there are changes within some module (e.g. :modules:libraries:util:core) by listening to something like modules/libraries/util/core/**/*, and then triggering a build of that changed module.
Now the issue I have is how to figure out where this module is used, so that I can build the other side also (in this example I would need to build :modules:backend:core once :modules:libraries:util:core is changed).
Is there some way to list all usages of given module ?
https://github.com/vanniktech/gradle-dependency-graph-generator-plugin
You can use this plugin to create "your project module dependency graph"
./gradlew generateProjectDependencyGraph
or "whole dependency graph".
./gradlew generateDependencyGraph
You can find this file from app/build/reports/dependency-graph and app/build/reports/project-dependency-graph directory.
The folder includes three files: png, svg and dot.
In the dot file, you can get the module dependency.
":app" -> ":base" ["style"="dotted"]
":app" -> ":moduleA" ["style"="dotted"]
":moduleA" -> ":base" ["style"="dotted"]
Related
I want to add a subproject to my Gradle project. The project is located somewhere on my hard disk drive, for example:
/A/Path/to/a/ProjectA
/Another/Path/to/another/ProjectB
What I want to achieve is to use ProjectB as a source module within Project A. However, all my attempts to do this so far - either by adding include /Another/Path/to/another/ProjectB or by adding include ':ProjectB'; project(':ProjectB').projectDir = ... in settings.gradle - just failed. Apparently, Gradle is not able to find the project.
How can I add ProjectB as a dependency without moving it from it's location?
Using Gradle 3.4.1, the following works for me (full example here):
include 'app', 'common'
def MY_PATH = '/Users/johndoe/foo'
assert new File("$MY_PATH/random/path/common").exists()
project(':common').projectDir = new File("$MY_PATH/random/path/common")
Thanks for your responses.
Turns out I've made several mistakes:
Adding the project to the built was dependent on the value of an environment variable. I replaced that with a property within gradle.properties.
I tested this by running the settings.gradle usind IntelliJ. I mistakingly expected this to work, but it didn't
I did not add the project as a dependency to the build.gradle file of the parent project.
It works now. Thank you all again!
I have a gradle project with many submodules named shared-library.
I have a project named service that depends on one of the modules of shared-library. e.g., it depends on :shared-library:module1. Normally, I get this dependency from maven.
Now I want to modify shared-library and test my changes using the dependent project. Instead of making a change to shared-library, building, deploying to maven, then rebuilding my service, I'd like to instead have service depend on the shared-library gradle project directly.
So I found out that you can point gradle to arbitrary project directories on the filesystem:
service/settings.gradle
include "shared-library"
project(":shared-library").projectDir = new File("/projects/shared-library")
But when I do this, the project is not aware of shared-library's submodules. I cannot do this:
service/build.gradle
compile(
project(":shared-library:module1"),
)
So I tried includeing them directly. :shared-library:module1 depends on :shared-library:module2 so I include that one as well:
service/settings.gradle
include "shared-library"
project(":shared-library").projectDir = new File("/projects/shared-library")
include "shared-library:module2"
include "shared-library:module1"
But now when I try to run this, it complains that :shared-library:module1 cannot locate a project named :module2. This is because its dependency is configured as such:
shared-library/module1/build.gradle
compile(
project(":module2")
)
But if I change that to an absolute project path, now shared-library cannot compile on its own:
shared-library/module1/build.gradle
compile(
project(":shared-library:module2")
)
tl;dr, it seems like there is a mismatch between the way service resolves the shared-library submodule names and how shared-library does it.
You're right. You can import an external project, or even external subprojects, and reference them in your main project, but as soon as you compile the external entities they fail to resolve with the expected names.
I found that you can rename the external projects in your main project so that they match the names of the external projects. That way your main project and the external projects use the same name.
Change your service/settings.gradle to:
include "shared-library"
project(":shared-library").projectDir = new File("/projects/shared-library")
include "shared-library:module2"
project('shared-library:module2').name = ':module2'
include "shared-library:module1"
project('shared-library:module1').name = ':module1'
Now in your project and external project refer to your modules always as :module1 and :module2. In service/build.gradle use:
compile(project(":module1"))
I have a several projects in a flat structure with dependencies between them.
Currently in each one a have a definition similar to this defining the versions used within the build script:
ext {
versions = [
scala: '2.11.1',
scalatra: '2.3.0',
jetty: '9.1.5.v20140505',
scalaTest: '2.3.0',
junit: '4.8.1',
]
}
and later usage:
compile group:'org.scala-lang' , name:'scala-library',version: versions.scala
As I have this defined in each build.gradle what I would rather want is to define the versions in one place and read in all files in the current build.
Writing to a global value will not be sufficient here as the combination of build files involved in a build may change (e.g. when testing a specific component only none of the components depending on it will be defined)
Put this map into its own .gradle file and include into your projects with apply from: '../dependencies.gradle'. Similar to what Gradle has in its own codebase
In a multi-project build I have a module that in itself is composed of two sub-projects. If I just want the option of building the top-level module but also ensure both the sub-projects within it are also built, how I do achieve this?
include 'moduleA', 'moduleB', 'moduleC' (root project settings.gradle)
project(':moduleC').projectDir = new File('path to custom module that includes sub-projects)
project(':moduleC').settingsDir = ?? (gradle fails because there is no settingsDir path)
but moduleC has a settings.gradle in itself that has
include 'api'
include 'server'
Now I want both these to be triggered when I specify gradlew :moduleC:build, but instead it just builds moduleC root project. Is there a way? This use case does seem valid to me (i.e. for modularity, you want to keep the inclusion of sub-projects at moduleC's level and not at root level).
Thanks,
Paddy
As of Gradle 2.2, only a single settings.gradle per build is supported. If that file contains include "moduleC:api" and include "moduleC:server", then running gradle build from moduleC's project directory will also build api and server.
I am building an Android Library project using the Android Gradle plugin (version 0.9.2) and it appears to have a bug (reported) in that while a "provided" dependency is correctly handled (not included) in the generated aar artifact, that dependency is incorrectly included in the generated debug test apk file.
It strikes me that a reasonable workaround is to remove the dependency jar file that is added by the :preDexDebugTest task as the last step for that task. But this task is dynamically generated so getting a handle to it is eluding me at the moment, hence the question.
In your app's build.gradle file, add
afterEvaluate {
def preDexDebugTest = tasks['preDexDebugTest']
// Do something with preDexDebugTest ...
}
That way it should be possible to operate on the preDexDebugTest task.