[GRADLE-1880] Eclipse task should warn the user when a web application relies on a module without eclipse-wtp plugin applied Created: 01/Nov/11  Updated: 06/Feb/17  Resolved: 03/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-5
Fix Version/s: None

Type: Improvement
Reporter: Sune Wettersteen Assignee: Unassigned
Resolution: Won't Fix Votes: 7

Attachments: Zip Archive gradle-eclipse-wtp.zip    
Issue Links:
Related to GRADLE-2834 eclipse-wtp plugin only respects proj... Resolved


The Eclipse task should warn the user when a web application module ("java", "war", "eclipse-wtp" plugins applied) relies on a module without wtp plugin applied ("java", "eclipse" plugins applied).

When a Java web application module A depends on a module B which doesn't have the eclipse-wtp plugin applied, the dependency will be added correctly in A but the necessary files wtp configuration files wont be created in module B. Both module A and B are created as valid eclipse projects, and module A will have a correct dependency on module B and all resources (classes, etc) will be shared correctly between the projects in eclipse. The deployment descriptor for module A in the WTP integration will however be invalid which means that module B will not correctly be deployed when using the WTP servlet container integration.

It may be fair to emit a warning when running the eclipse task that module A depends on a module that does not have the eclipse-wtp plugin applied (but has the eclipse plugin applied). It may also be fair to note in the documentation that the eclipse-wtp plugin is not only used for modules applying the "war" plugin, but should also be applied to modules that these modules depend on.

I've attached a simple example which illustrates the problem.

Comment by Kris De Volder [ 04/Jan/12 ]

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:

Comment by Szczepan Faber [ 10/Mar/12 ]

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

Comment by Kris De Volder [ 13/Mar/12 ]

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).

Comment by Szczepan Faber [ 13/Mar/12 ]

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).

Comment by Sebastien Tardif [ 25/Sep/13 ]

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.

Comment by Nemanja Nedic [ 25/Feb/14 ]

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

Comment by Andreas Schmid [ 07/Dec/14 ]

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

Comment by Andreas Schmid [ 05/Mar/15 ]

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

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Mauro Molinari [ 15/Nov/16 ]

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.

Comment by Andreas Schmid [ 15/Nov/16 ]

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

Comment by Donát Csikós [ 03/Feb/17 ]

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.

Comment by Mauro Molinari [ 06/Feb/17 ]

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

Generated at Wed Jun 30 12:06:51 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.