Project Dependency for ear / war not working

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 { deploy project(path: ':war', configuration: 'archives') }

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