[GRADLE-698] Automatically add the repository locations of dependent sub-projects to the parent project when bundling all transitive dependencies (ie. into a WAR) Created: 13/Oct/09  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.8
Fix Version/s: None

Type: Improvement
Reporter: Andrew Schoewe Assignee: Unassigned
Resolution: Won't Fix Votes: 1

Issue Links:
Duplicates GRADLE-1599 Project transitive dependency resolut... Resolved
Duplicates GRADLE-1940 Unresolved dependencies when project ... Resolved


I have a WAR project that depends on a number of other projects -the jars produced by the sub-projects. This means that my WAR project has a compile time dependency on my sub projects. Obviously, when I create my WAR, it will need to bundle the runtime dependencies of my sub projects. This is where I'm having a problem. All of the runtime dependencies of the sub-projects live in the 'lib' folder of the each sub-project. I noticed that Gradle only looks in the lib folder (repository) of the WAR when trying to find these run-time dependencies.

I would like to have Gradle automatically look in the 'lib' folder of each sub-project for the appropriate transitive jars when building a WAR

Adam Murdoch provided the following workaround for this typical situation:

Add this to the root build file...

allprojects {
afterEvaluate { project ->
project.configurations.each { config ->
config.getDependencies(ProjectDependency.class).each {dep ->
dep.dependencyProject.repositories.each {repos ->
if (!project.repositories.all.contains(repos))

{ project.repositories.add(repos) }


The only concern here is that each sub-project will need to have uniquely named repositories. This is not a major problem, but something to be aware of.

Here is the original message that started this conversation: http://www.nabble.com/Bundling-transitive-jars-in-WAR-td25862878.html

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:36:34 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.