Thanks for explaining the background.
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
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
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