On Dec 18, 2008, at 5:12 PM, Gennadiy Shafranovich wrote:
I have a multi project build that results in a WAR file that i am
trying to manage with gradle. The goal is to have a war thats
buildable with gradle and be able to deploy and test app via
eclipse's tomcat integration at the same time. The secondary goal is
for other developers on the project not having to generate or change
any eclipse settings to get this done (beyond creating a new server
in the server tab).
I've set up build.gradle files in all sub projects and a master
project with the main settings and build file as well. I got gradle
to generate a working war file and eclipse project files for all
subprojects. Most of these work very well, all dependencies are
reflected in the class path and project references. One problem i am
running into is on the sub project which holds the web app. It is
being build using the war plugin in gradle and has the following
settings via the build.gradle file:
import org.gradle.api.tasks.ide.eclipse.ProjectType;
usePlugin('war')
eclipseProject {
projectName = 'web'
projectType = ProjectType.WTP_WEBAPP
}
eclipseWtp {
deployName = 'gradleTest'
}
archive_war {
baseName = 'gradleTest'
}
When genaring eclipse projects files using this settings almost
everything works. The only thing missing is that the other sub
projects (holding utilities) are unchecked in the "Java EE Module
Dependencies" settings section of the project. This is needed for
eclipse to be able to build and deploy the project to a test tomcat
instance in the same way as gradle composes its WAR file.
I figured out that the projectDependencies property
(setProjectDependencies and getProjectDependencies) controls wether
this is done but i could not figure out how to construct instances
of DefaultProjectDependencies and not sure if i need to do this
anyway. The solution turned out to be changing the eclipseWtp
settings to the following:
eclipseWtp {
deployName = 'gradleTest'
projectDependencies = projectDependencies
}
This is strange. So the behavior of eclipseWtp is different without
the line: 'projectDependencies = projectDependencies' ?
The magic is calling the setter with the results of the getter. This
works because the source reads as follows (javadocs removed):
public List<DefaultProjectDependency> getProjectDependencies() {
return (List<DefaultProjectDependency>)
conv(projectDependencies, "projectDependencies");
}
public void
setProjectDependencies(List<DefaultProjectDependency>
projectDependencies) {
this.projectDependencies = projectDependencies;
}
To a java programmer and being new with groovy/gradle i am very
surprised to see the setter operate on a local var while the getter
operate on the convinience object. Is this correct behavior?
This is nothing Groovy specific. As you have seen, the EclipseWtp
class is a Java class and can be used as such. The objectives behind
all this is the following:
For us it was important to decouple the tasks from any specific build-
by-convention behavior yet they should be able to expose build-by-
convention behavior. A task is supposed to solve its own problem space
in an optimized manner (with an own API) without being coupled to
other tasks and without a strong coupling to other elements of the
Java plugin. It is the job of the plugin to pre-configure tasks and
glue them together by dependsOn relations but also by sharing common
properties. But the user can change the values of those common
properties. Therefore it is not good enough for the plugin to just set
the properties of the tasks to the initial value of the common
properties. Later changes by the user wouldn't be reflected by the
tasks any longer.
To solve this, a ConventionTask behaves in the following way. The
value of its properties are null by default. If they are null and one
is calling a getter on this property, the shared convention value for
this property is returned. If you set the property to a non null
value, then the task returns not the common convention value any
longer, but this new task specific property.
<snip>
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
