This is quite a devious problem... projects that have this problem look 'ok' in every way, yet they don't deploy properly. It would be quite hard for a user to determine what the problem is.

I've added my vote for this issue, i.e. I think it would be very good if there would be some kind of error/warning to explain to a user it isn't a good idea to have WTP projects depending on non-WTP projects.

Example of a problem caused by this issue that was reported as a bug against STS gradle tooling:
https://issuetracker.springsource.com/browse/STS-2192

So Kris, will you be happy with just a warning emitted to the console?

I guess so. Unless there is another / better way.

For now it will have to do. In the longer term perhaps we should start putting some thought into ways that Gradle models pr task executions could attach error and warning markers to resources in the project (i.e. create a concept similar to Eclipse's marker in Gradle tooling API).

This something that could be modelled explicitly at some point. You'd get some kind of Warning object that contains useful information - for example the stuff you mentioned (resource name, line number, etc).

It's sound wrong that modules (simple jars) used by a WAR project need to apply the eclipse-wtp plugin. The jar has nothing to do with wtp.

In the spirit of this issue, it seems the current usage is that if you ever use eclipse-wtp, you should be using it everywhere.

Any progress on this issue? Having to enable eclipse-wtp plugin on all modules isn't really a solution.

Yes, I have created a patch, see https://github.com/gradle/gradle/pull/361.

Pull request was not accepted because another solution is prefered, see https://github.com/gradle/gradle/pull/361.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

I think this is still a grey area and honestly I don't understand if something has been done or not (it seems like Andreas's PR was rejected, but I can't understand if some alternative solution was applied.
It is not yet clear to me if I should apply eclipse-wtp plugin to any dependency of a "war" project when I use Eclipse with WTP.

Hi @mauromol,
as far as I can see, there was no other solution to this. They agreed that the "magical behavior" is OK in there opinion. It is kind of documented by

The eclipse-wtp plugin generates all WTP settings files and enhances the .project file. If a Java or War is applied, .classpath will be extended to get a proper packaging structure for this utility library or web application project.

on https://docs.gradle.org/current/userguide/eclipse_plugin.html if you read clearly and a bit between the lines

I agree with Andreas, it's a bit vaguely phrased, but Gradle behaves as the documentation says. Imho there is no need for a warning, at least not at this level of integration. I'm going to close this issue, but - as explained above - we can always continue the conversation on GitHub.

I opened https://github.com/gradle/gradle/issues/1333 because I'm still convinced the current situation should be improved.