I'm wondering (from a quick glance) whether this might be related to the fix that was made for GRADLE-687 and GRADLE-1269

See also http://forums.gradle.org/gradle/topics/problem_with_the_ear_plugin and http://gradle.1045684.n5.nabble.com/Ear-plugin-does-not-include-my-war-files-in-milestone-5-td4980884.html (where I have a small example).

Just hit this. Our solution will probably be to add a "wars" configuration to all projects with the war plugin, and use that for publishing just the war artifact.

But generally, we've run into this issue in many different forms. There is a general...lack of a best practice for selectively depending on particular artifacts of another project. We've needed several times to say "I depend only on the .war artifact of subproject X" or "only on the X-fat.jar" or "the .jar, sources.jar, and javadoc.jar" or "the X-bin.tar, but not the X-source.tar or X-all.tar" etc.

In most cases this comes up in assembly types of projects (like an ear project, or a project used to bundle our product into distribution tars), though we also had a case where we'd developed some re-usable shell scripts and .conf files that were pulled into other projects as dependencies.

I think the appropriate practice is to define publish configurations for each unique subset of files? This is what we've been doing so far. Though it means the publishing project needs to know a priori what subsets of its published artifacts other projects might depend on, which is a little wonky.

I guess the alternative is Maven's approach of 1 project = 1 artifact. Then every single unique artifact has a unique locator/name that other projects can refer to. When gradle projects publish multiple artifacts, those artifacts may or may not have unique names to refer to them. And project() type dependencies don't really make it clear how you would refer to specific artifacts anyway (can't use classifier or artifact keys like you can with module dependencies).

This behavior seems very wrong. If I have a WAR project, why should my dependency on it imply that I want the JAR instead?

I assume the fix for this would be to add the WAR to the runtime configuration and remove the JAR.

I don't really understand the use case for GRADLE-687 and GRADLE-1269. Can anyone explain that better?

Could you please fix this issue? We must stick to Milestone 4 as long as this issue is not fixed. And we want to upgrade Gradle as soon as possible.

Spencer Allain shows a way around the problem here: http://forums.gradle.org/gradle/topics/problem_with_the_ear_plugin

That said, this is a pretty daft bug, which everyone dealing with wars in ears will encounter.

The workaround which Spencer Allain shows in the thread mentioned above is working for me. Thank you for posting this hint.

Workaround by Spencer Allain:

dependencies

I also ran into this issue and did this to workaround. Not as pretty.

deploy fileTree(new File(project(':war').buildDir,'libs'))

I totally agree with Andrew Oberstar: GRADLE-687 and GRADLE-1269 made things much worse because now you have to take additional steps if you want the most common behavior. This seems very wrong. If someone wanted a jar instead of a war, he could've created a multi-project build with jar and war subprojects.

Here's a working workarount:

In the war project:

// When we user this project's "archives" configuration, we don't want the jar
jar.enabled = false

In the ear project:

dependencies {
    deploy project(path: ':war-project', configuration: 'archives')
}

Whatever you do, you should at least update the documentation at: http://gradle.org/docs/current/userguide/ear_plugin.html#sec:customizing Because that just doesn't work.

Best regards,
Mike

Agree this is totally wrong, had one of my developers waste best part of 1/2 a day on this. The docs are wrong, if you follow the EAR and WAR example JAR's get published in the ear not the WAR.

Chapter 26 first paragraph is also incorrect "The War plugin extends the Java plugin to add support for assembling web application WAR files. It disables the default JAR archive generation of the Java plugin and adds a default WAR archive task." If the project has the WAR plugin the jar is built you have to add "jar.enabled = false" to stop the jar being built.

I agree with Paul on this. I also wasted half a day not dbl checking the result within the sample ears, until I tried them and found they have the same issue as mine.
Even though there is a workaround (ore feature in the given the timeframe of this issue) the samples still have this issue, since 2011.
This issue was reported years ago and even though there is a workaround available (or more like a feature in the meantime) the samples still don't work. As Gradle is now moving fast towards version 2.0, such low hanging fruits should be fixed right away.

I assume nobody is building EARs with Gradle, since this problem completely breaks the "out-of-the-box" experience of Gradle with the EAR plugin... and this bug is 5 years old!!

I've corrected the documentation for Gradle 3.1. So at least the documentation will no longer confuse users.

Fixing the actual issue will be harder. Essentially we will need usage-aware dependency resolution to tell apart the case of "I want to compile against this project" vs "I want to package this project for deployment".

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!

I think this is still an issue in recent Gradle, as per Stefan's comment on 2016-08-27.

Moved to https://github.com/gradle/gradle/issues/1353 — please make sure I interpreted this issue correctly and continue discussion there.