Home » Java » java – Gradle: Add dependency of subproject as dependency of the root project-Exceptionshub

java – Gradle: Add dependency of subproject as dependency of the root project-Exceptionshub

Posted by: admin February 25, 2020 Leave a comment


We are running our Java EE applications in WAS 8.5 and Gradle 5.* to build them.

In the past we packaged our .war application in an .ear archive, which we then deployed on our server. We had to separate our libraries from our applications and include them as shared libraries, because in our experience it made deploying much slower and in some cases used up all system memory, crashing the server.

After some experimentation, we realized that we don’t need to extract the dependencies into shared libraries, because we can include them in the lib folder of our .ear archive.

Currently, we get this done by defining the dependencies of our .war application as compileOnly and redefining them as earlib in the root project (which generates the .ear archive). I’m looking for a way to automate this procedure.

The script I used looks something like this:

project.configurations.named('deploy').getAllDependencies().withType(ProjectDependency.class).forEach({dependency ->

// This loosely resembles the actual code I used. The thought process is right, it just might have a couple syntax errors.

// Obviously, I defined an `earlib` configuration in the subproject

I tried running this code in the configuration phase, as well as in the doFirst{} section of the ear task. They all had different problems.

The former didn’t work, because it seems like in the configuration phase when this code ran, the dependencies weren’t configured yet.

The latter didn’t work, because I can’t just add dependencies during runtime (thinking back, it sounds ridiculous that I even tried it).

My question is: Can I find a phase in the build lifecycle, where I can find and modify the dependencies? Is there another workaround to solve my problem?

How to&Answers:

The technical answer to your questions is that you can use either:

  • A configuration.incoming.beforeResolve hook to do it last minute, only when the configuration really needs to be resolved.
  • Use an afterEvaluate block, assuming all the other dependencies are not defined in an afterEvaluate themselves.

However, the right solution would be to leverage the dependency management engine of Gradle and effectively declare that your root project, the one building the EAR, has dependencies on the specific configurations of the subprojects.

Not knowing your full setup and details, I believe the above would still be the more correct solution, though you may have to filter the subproject artifacts from the resulting graph.

Ideas on how this works in recent Gradle version: https://docs.gradle.org/6.2/userguide/cross_project_publications.html Most of the things explained there should work with the latest 5.x versions.