Following is the description of the possible workaround that solved the problem for me at the moment

• taken from the mailing list, provided by Adam Murdoch:

"A work around is to enable the 'jar' task, and add it back to the 'archives' configuration:

jar.enabled = true
artifacts

It's not a perfect work around, in that you end up with both the jar and war in the compile and runtime classpath, which can be a problem if you then bundle some kind of distribution, or another war, in a dependent project."

Is there any plan to address this completely? Meaning, a way to include the project simply in jar format only, without also pulling in the war?

This is duplicated in gradle-687, but there might be different watchers.

While not particularly pretty, and uses an internal api, this gets rid of the war file from the archives (and the classpath), so that normal dependencies work.

import org.gradle.api.internal.artifacts.publish.ArchivePublishArtifact;

Configuration archivesConfig = project.getConfigurations().getByName("archives")
Task warTask = project.getTasks().getByName("war")
for (PublishArtifact publishArtifact : archivesConfig.getAllArtifacts()) {
  if (publishArtifact instanceof ArchivePublishArtifact) {
    ArchivePublishArtifact archivePublishArtifact =
      (ArchivePublishArtifact)publishArtifact;
    if (archivePublishArtifact.getArchiveTask() == warTask) {
      archivesConfig.removeArtifact(publishArtifact);
    }
  }
}

You can also check the mailing list, where I describe this pattern, plus some additions that allow for easily wiring up multiple wars to one or more ears.

http://markmail.org/message/retujvgi7jjmza73

-Spencer