Bug in v2.1-rc-4: EAR plugin is not generating WAR artifacts properly and thus invalid EAR files

I posted a similar report 6 days ago about v2.1-rc-2 and haven’t received any responses to it. I also see outstanding bugs in JIRA from over a year ago related to defects in the EAR plugin. The EAR plugin needs some love.

I’d like to get a timeframe on when this bug will be addressed as generating proper, compliant and deployable EAR file is a baseline requirement for us to use Gradle. Please advise when a fix can make it in, or if there are any updated workarounds.

Here are specifics on the problem:

The Ear plugin is not generating WAR artifacts properly and the v1.x work around is no longer working with v2.x. Using the samples provided with v2.1-rc-4 demonstrate this problem. In specific, in samples/ear/earWithWar, when you run ‘gradle ear’ it generates an ear file, however the war project is not generated as a war… it’s generated as a jar file and placed in the ear file an ejb module. Not generating it as a war, means that the file extension is wrong and the additional resources are not included. In other words in the ear is “war.jar”, not “war.war” and the deployment descriptor lacks the necessary entry for a war file:


It does have (and should not have):


This is not correct because doing it this way deploys the war as an ejb-jar…which it is not. As built, this sample ear is not spec compliant and won’t deploy.

Is there a specific bug report in JIRA that addresses this yet?

I didn’t see one…but didn’t do a through search.

@Peter Luttrell: can you provide the link to your orginal post re rc2 please, I’m having trouble finding it.

If you use this dependency declaration, you’ll end up with the war in the ear:

dependencies {

deploy project(path: ‘:war’, configuration: ‘archives’)


The OP should determine whether this fixes his problem, but it still sounds like a workaround to me.

@Peter Luttrell: you should file a bug report whether this fixes the problem or not, and you should add the information about this workaround (again, even if it doesn’t work) to the ticket.

Here’s a link to the rc2 post: http://forums.gradle.org/gradle/topics/ear-plugin-is-not-generating-war-artifacts-properly-and-the-v1-x-work-around-is-no-longer-working-with-v2

The solution posted by Adam does generate a proper EAR file with a proper war file and has me up and running. Thank you very much for providing it!

When I was working on this originally, I saw someone on StackOverflow post a similar solution, but I couldn’t get it to work. This is why I mentioned the v1 workaround was not working.

In my opinion, this feels like a work around to me as well. Partially because it’s not as clear and elegant as everything else in Gradle that I see has been, in addition this isn’t documented in any documentation that I could find. Not sure if this will work from a Gradle internals standpoint, but perhaps this might be a solution: 1) Deprecate the current dependency configuration ‘deploy’. 2) Create a new dependency configuration called ‘deploy-ejb’, which functions exactly as the current ‘deploy’ does today, which is to say that it currently adds element in the application.xml in the ear. 3) Create a new dependency configuration called ‘deploy-web’, which would properly create elements in the application.xml in the ear. Basically the same thing as ‘project(path: ‘:war’, configuration: ‘archives’)’.

If Adam’s solution is the long term solution, then the ear samples need to be updated to show this and the documentation (chapter 27) should be updated to include this detail as well. I’d be happy to create a bug report to capture these items, if someone can grant my JIRA account (pluttrell [at] gmail.com) permissions to do so. Gradle has been one of best documented and easy to learn open source tools that I’ve ever come across…looking forward to have the EAR plugin hitting this mark as well.

Did you guys still want me to create a ticket in JIRA?