[GRADLE-2575] Generated ivy.xml is incorrect for project with 'war' plugin applied Created: 28/Nov/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

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

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 1


 Description   

Given this Gradle file:

apply plugin: 'java'
apply plugin: 'war'

And assuming there is some code in src/main/webapps, when running 'uploadArchives' Gradle generates the following ivy.xml:

<ivy-module version="2.0" xmlns:m="http://ant.apache.org/ivy/maven">
<info organisation=""
module="gradleTestProj"
revision="unspecified"
status="integration"
publication="20121128085624"
/>
<configurations>
<conf name="archives" visibility="public" description="Configuration for archive artifacts."/>
<conf name="compile" visibility="private" description="Classpath for compiling the main sources." extends="providedCompile"/>
<conf name="default" visibility="public" description="Configuration for default artifacts." extends="runtime"/>
<conf name="providedCompile" visibility="private" description="Additional compile classpath for libraries that should not be part of the WAR archive."/>
<conf name="providedRuntime" visibility="private" description="Additional runtime classpath for libraries that should not be part of the WAR archive." extends="providedCompile"/>
<conf name="runtime" visibility="private" description="Classpath for running the compiled main classes." extends="compile,providedRuntime"/>
<conf name="testCompile" visibility="private" description="Classpath for compiling the test sources." extends="compile"/>
<conf name="testRuntime" visibility="private" description="Classpath for running the compiled test classes." extends="runtime,testCompile"/>
</configurations>
<publications>
<artifact name="gradleTestProj" type="war" ext="war" conf="archives"/>
<artifact name="gradleTestProj" type="jar" ext="jar" conf="runtime"/>
</publications>
</ivy-module>

As you can, see an artifact exists in the section that is never actually created. Worse, the war file is not part of the runtime configuration, so other projects that include this war as a dependency will be unable to locate the actual published artifact.

I need the 'uploadArchives' task to generate an ivy.xml file for the war much the same way it does for a jar. If I convert my project to a jar, it generates a publications sections like so:

<publications>
<artifact name="gradleTestProj" type="jar" ext="jar" conf="archives,runtime"/>
</publications>

Is this behavior intended? Is there a workaround for it?

 Comments   
Comment by Gradle Forums [ 28/Nov/12 ]

We're aware of a number of issues with ivy.xml & pom.xml generation for 'war' projects. We're currently working on new plugins for publication that will address these (and other) issues. Gradle 1.3 introduced the first iteration of this new [1]ivy-publish plugin, that gives you the ability to modify the generated ivy.xml file before uploading.

You may be able to use this plugin to workaround the current limitations: in the future this plugin will "just work" for publishing web applications.
----------------------------------------------------------------------------------------
[1] http://www.gradle.org/docs/current/userguide/userguide_single.html#publishing_ivy

Comment by Ryan Nelson [ 08/Jul/13 ]

FYI, I believe this problem is resolved as of Gradle 1.5 using the ivy-publish plugin. That plugin no longer creates the jar entry in the ivy.xml as explained in the original post. It also eliminates the dependencies section (which really doesn't make sense for a WAR, which packages its dependencies internally), and replaces the "archives" configuration with a "master" configuration that is inherited by "default".

All of these changes make it possible to include the war as a dependency in another project, so I think this issue can be closed.

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 12:25:39 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.