Thanks for you reply. After a closer look this seems to be an eclipse issue and not a gradle issue. I've looked into the WST files the eclipseWtp task generates and at those that eclipse generates with a manual setup, and references to the utility project exist in both and in the same format.
>From my end it looks like there is some cache in the workspace in eclipse that keeps this information after it is set on the front end. I have taken my projects, deleted all .project .classpath and .setting eclipse files and moved them to a fresh workspace. After that i had gradle generate all eclipse files and launched the IDE itself. What i found is that the java EE module dependcies were correctly read by eclipse and the checkboxes were checked correctly. As i said, my guess is that something in the workspace itself stores some of this info. I have revised my build.gradle file to remove the unessesary mention of the projectDepenencies as these seem to be set correctly by setting these projects as runtime dependencies. Thanks for your help. On Fri, Dec 19, 2008 at 5:03 AM, Hans Dockter <[email protected]> wrote: > > 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 > > >
