[GRADLE-1377] gradle Eclipse plugin should allow simple method to set jst.web value Created: 06/Feb/11  Updated: 29/Nov/16  Resolved: 29/Nov/16

Status: Resolved
Project: Gradle
Affects Version/s: 0.9.2
Fix Version/s: None

Type: Bug
Reporter: Daniel Joyce Assignee: Unassigned
Resolution: Duplicate Votes: 3


When building eclipse project files, gradle eclipse always defaults to setting jst.web to 2.4, which is YEARS old. There should be a simple way to set this.

A workaround is given here:


Comment by Umit [ 08/Sep/11 ]

The provided workaround needs a little modification as of version 1.0-milestone-3.
Just change 'eclipseWtp' to 'eclipseWtpFacet', so that it should be:

eclipseWtpFacet.whenConfigured { config ->
    config.facets.each {
        if (it.name == 'jst.web') {
            it.version =
                    it.group == 'javax.servlet' && it.name == 'servlet-api'
Comment by Umit [ 13/Nov/12 ]

In gradle Milestone 6, whenConfigured is deprecated. Here's an updated solution:

eclipse {
    wtp {
        facet {
          file {
            whenMerged { config ->
                config.facets.each {
                    if (it.name == 'jst.web') {
                        it.version = 3.0 
Comment by Andreas Schmid [ 26/Oct/14 ]

Currently the default jst.web for a war project is still 2.4. Though, if you have the war plugin applied to your project, you can easily change this as GRADLE-2186 which I am currently working on?

Comment by Michael Russo [ 07/Dec/14 ]

I believe the issue here is twofold, (1) jst.web default version is very old, and (2) it should be easier to configure this setting, which is so often wrong for any modern web project. The solution offered, while valid, adds several lines of configuration bloat to adjust this one setting.

Perhaps if there was a special property of the eclipse configuration to adjust this default, such as eclipse.wtp.defaultJstWebVersion or something? Setting this property would easily adjust the jst.web version in a single line. I believe this is what the reporter, along with myself and others, are looking for.

Comment by Andreas Schmid [ 07/Dec/14 ]

Thanks for your answer. I understand your problem and I could provide a solutions satisfying your suggestions. Can you just tell me what is the difference applying a newer version of jst.web? As this is very special for a war project, I am currently not convienced adding a special feature for this which is not used at all in 90% of all projects (if we just upgrade jst.web to a newer version) ...

By the way, you could also write the fix down in one line

eclipse.wtp.facet.file.whenMerged { f -> f.facets.each { if (it.name == 'jst.web') it.version = 3.0 } }

Nevertheless, if you can tell me the differences setting newer version, we can at least update this to >= 3.0.

Comment by Michael Russo [ 07/Dec/14 ]

Yeah, I know it's a "one-line fix", but the argument is that it isn't "easily exposed" for something that is wrong, more often than not.

the jst.web version should coincide with the Java Servlet version that the given project is being designed for. This affects eclipse's project validations and, IIRC, it affects eclipse's server deployment as well. It has been a while since I've tried forcing a web project to be 2.4, but I think eclipse may prevent deployment of such a project to newer servlet containers. I'll be sure to test this if you need a more confident answer.

I can say that I've seen many guides for changing this specific property, and I don't think people would be interested in changing this version if it had no impact on project configuration.

Comment by Andreas Schmid [ 14/Dec/14 ]

If the jst.web version coincides with the Java servlet version, we maybe should introduce a property having such a name That would be my preferred solution.

Do you have any documentation about the jst.web > 2.4? I have just found http://www.eclipse.org/webtools/development/proposals/WtpProjectFacets.html which stops with 2.4.

@Radim Kubacki: what do you and your collegues at Gradleware think?

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 Andrew Oberstar [ 29/Nov/16 ]

I created an issue for this https://github.com/gradle/gradle/issues/945

Generated at Wed Jun 30 11:54:00 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.