One of the coolest features that have been added to Gradle recently are composite builds (as I think, and amongst others, of course). However, when it was released it was stated that Eclipse WTP projects are currently not supported; see this announcement as well as this reply. The latter makes the statement that
This will be improved within the first half of this year.
I would like to kindly ask what the current state of this issue is. Can we expect it to be released soon? Is there an issue where we can follow progress of this issue? Apologies if it has been released already and I’m just not seeing it.
The problem is that our integration with WTP currently comes down to calling the eclipseWtp task (as opposed to the JDT integration, where we have a rich model of the classpath that we pass from Gradle to Buildship). Calling tasks in nested builds is currently not supported by Gradle. However, you can work around this by making the eclipseWtp task of the root build depend on the eclipseWtp task of the included builds:
This will run the eclipseWtp task on the root project of each included build. If the included builds are multi-project builds, you’ll need to do some additional work to make sure that the WTP setup for all subprojects is run. In the simplest case this could be a line like this:
eclipseWtp.dependsOn subprojects*.eclipseWtp
Since even this simplified example is a bit awkward, we went with the “not supported” statement.
Unfortunately this was trumped by other priorities and hasn’t been implemented yet. As far as I know there is no plan to implement it this year. You can follow/upvote this issue, which is the Gradle feature that Buildship is currently blocked on.
Considering the workaround you described, let me describe the use case that I’m actually trying to solve, which is different from what you described and therefore I’m now closer to the point where I think that it should actually work.
Suppose there are two projects lib and app. Suppose both are multi-project builds (flat hierarchy located in the same parent folder). Some sub projects in app apply the eclipse-wtp plugin, but no sub project of lib applies it (which is what makes it different from what you described if I understand it correctly). Some sub-projects of app specify compile- and/or runtimetime dependencies on some sub projects of lib. Suppose we are in the root project of app and run
gradle --include-build ../lib eclipse
As I read your reply, support of Eclipse WTP for composite builds concerns only (sub) project builds included in a build, not the top level build (app in this case). Correct? My understanding was that Eclipse WTP is generally not supported for composite builds (in the example not for app). Anyway, does it mean that the example described should work (because no sub project of lib applies eclipse-wtp), meaning that in Eclipse (i) those sub projects of app that define dependencies of sub projects of lib should reference them as project references and, more importantly, that (ii) Eclipse’ deployment assembly is also configured correctly for those sub projects of app that apply eclipseWtp. Or is there more to be done?
What I can add to this from a project setup that essentially matches the example described is that (i) is definitely the case but (ii) doesn’t seem to be correct as I’m getting ClassNotFoundExceptions at runtime when I start the app in Eclipse using a server such as Tomcat or JBoss, which is not the case if Eclipse project configuration files are created using gradle eclipse in app.
If I remember correctly, WTP would only allow referencing libraries that also have proper WTP configuration. If you have a small example we can put that to the test and maybe find a workaround.