On 21/12/2010, at 8:54 AM, mraccola wrote: > > I am trying to setup a Gradle build for a multi-module project. > > I have multiple "WAR projects". For each WAR project I have configured the > "war" plugin and used the "ecilpseWtp" task to configure the project. This > is handled nicely by the build in Gradle functionality. > > Each of the WAR projects has dependencies on 3rd party JAR files. The > "eclipseWtp" task handles these dependencies properly by adding > "dependent-module" entries in the org.eclipse.wst.common.component file. > > Each of the WAR projects has dependencies on other projects in the > workspace. The "eclipseWtp" task adds "dependent-module" entries for these, > however, this is not sufficient for getting these to work with WTP. In > order to get them to work with WTP the Eclipse meta data in the dependent > modules themselves must also be modified. Specifically, the > org.eclipse.wst.common.modulecore.ModuleCoreNature nature must be added to > the dependent project. > > Then there is the case of transitive (or second-level dependencies). If > "WAR Project A" has a compile dependency on "Project B" and "Project B" has > a compile dependency on "Project C" and "commons-logging-1.1.1" then all 3 > dependent JAR files should be present in the WEB-INF/lib folder when the WAR > project is deployed. This does not appear to be supported by the Gradle > functionality. In order for this to occur the Eclipse meta data in the > dependent modules themselves must also be modified. The way this is handled > is different depending on the type of dependency. For project dependencies > an "dependent-module" entry must exist in the > org.eclipse.wst.common.component file. For 3rd-party dependencies an > attribute must be added to the "classpathentry" in the .classpath file. > > Perhaps I am missing something. Does Gradle support all of this WTP > functionality or does it only support simple cases?
It looks like the eclipse plugin only supports the simple cases. The war plugin, on the other hand, supports any case. None of the Gradle developers is an eclipse user, so the eclipse plugin is not as good as it could be. Personally, I find it difficult to know if I've configured eclipse properly, or at least the way that an eclipse user would expect (this is just a lack of experience with eclipse). This means we depend on feedback from real eclipse users about what is broken or could be improved. Your description of the problem, and how to fix it, is really, really helpful. Could you put this information in a jira issue? > > I have tried applying the "eclipseWtp" on the non-WAR projects in hopes that > it would be smart enough to generate the meta data ... but the "eclipseWtp" > task is actually registered by the "war" plugin so it is obviously not > designed to do this. > > Can you please give me a tip on how to do it correctly or let me know what > the timeline is for filling out the missing peices? We can't really give you a timeline for a fix. We'll probably do another round of fixes to the IDE plugins early next year. Of course, patches are always welcome. You can most likely work around the problem by configuring the eclipseProject task of the other projects to add in the nature, and configuring the eclipseClasspath task to add the attributes. Have a look at the documentation for these tasks: http://gradle.org/0.9/docs/dsl/org.gradle.plugins.eclipse.EclipseProject.html and http://gradle.org/0.9/docs/dsl/org.gradle.plugins.eclipse.EclipseClasspath.html -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
