[GRADLE-510] behaviour of dependencies of WAR plugin in a multiple project environment Created: 28/May/09  Updated: 10/Feb/17  Resolved: 10/Feb/17

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

Type: Bug
Reporter: Erwan Lacoste Assignee: Unassigned
Resolution: Won't Fix Votes: 2

Attachments: File base.build.gadle     File jar.build.gradle     File war.build.gradle    

 Description   

environment:
multi-project, with one project for the main core module, one project as war project. the main core is a web module for the war project.

when packaging the WAR file, we wish to package in lib folder:

  • a JAR file of the core project
  • all libs required by the core project (compile and runtime), transitively
  • all the libs from the war project (compile and runtime), transitively

The question is:

  • should we include libs marked as providedCompile or providedRuntime? NO
  • should we include libs marked as providedCompile or providedRuntime in the WAR dependencies, but marked as compile or runtime in the required project?

The second question needs a test case.

I've included 3 files as a base for a test case (didn't test them, but main idea is there).

 Comments   
Comment by Hans Dockter [ 28/May/09 ]

Thanks a lot.

Comment by Mauro Molinari [ 24/Nov/11 ]

Forgive me if I don't understand the description of this bug properly.
However, what I've found myself and I think is a problem is the following:

  • project A applies 'war' plugin
  • project B applies 'war' plugin
  • project A depends on B
  • if B declares some dependencies as providedCompile/providedRuntime, they are still included in A.war unless A itself declares those dependencies as providedCompile/providedRuntime

I think those dependencies should NOT be included in A.war, unless some other project A depends on declare them as standard compile/runtime dependencies.

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:31:56 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.