On 15/06/10 11:08 PM, Spencer Allain wrote:
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.
Absolutely. I would really like to fix this. However, it needs a few
changes to the dependency management API so that it works well
regardless of whether the war is published or not. These changes we were
planing on doing after 0.9 is released. Given that there is a work
around, I'd rather get 0.9 finished up, and then look at fixing the problem.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
