So I've been able to avoid the war plugin problem for some time, but it has
come back around, and it seems there are still "issues" with how gradle treats
things.
Consider subprojects A, B and C. B and C depend upon A which now uses the war
plugin and creates a jar.
gradle -t within the B project produces the below:
:B:compileJava - Compiles the main Java source.
-> A:jar, :A:war
Not sure why compileJava would depend upon the jar and war tasks, other than
that maybe it explicitly is depending upon the artifacts produced by the A
project.
:B:compileJava
warning: [path] Unexpected extension for archive file:
/tmp/project/A/build/libs/A-1.0.0.war
Obviously the java compiler doesn't like to depend upon war files.
The next piece of the equation is that the war task sucks in the A.war file in
addition to the A.jar file (actually it only "sees" the A.jar file since I
re-enabled it, and added it back to the archives artifacts, as compilation
simply fails otherwise -- which means B:compileJava does not look into the
A:build:classes directory for it's compile-time classpath).
I'm also attempting to build an ear file (which I was hoping to model upon the
war file task, but am not so sure it's flexible enough at this time). Ears are
obviously tougher, as sometimes you want the jar, and sometimes you want a
war. The default logic would be, if I found a war, use that, otherwise grab
the jar file -- at least that'd be my assumption behavior.
If the war task only tried to grab archive artifacts that were _NOT_ of
type/extension war, then I'd be fine (although there would still be the
warnings at compile time until that portion of the issue is resolved).
I'd rather not go back to my original hack that simply removed the war from the
archive artifacts, but that might be the only "good" solution until mixed
jar/war projects are worked out in gradle.
jar.enabled = true
jar.version = version
artifacts {
archives jar
}
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);
}
}
}
This allows me to compile fine without warnings against a "war"-based plugin
project, and properly suck in just the jar file into another war. It obviously
will not publish the war artifact anywhere, but we don't do that, so it's not
missed.
I know it hasn't been a priority for 0.9, but separation of the artifacts for
publication and the classpaths and artifacts for inclusion in other types of
projects (i.e. war and eventually ear) needs to be made easier.
-Spencer
