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 =
                configurations.providedCompile.getAllDependencies().find{
                    it.group == 'javax.servlet' && it.name == 'servlet-api'
                }.version
        }
    }
    config.facets.unique()
}

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 
                    }   
                }   
                config.facets.unique()
            }   
          }   
        }   
    }   
}

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?

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.

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.

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.

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?

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 created an issue for this https://github.com/gradle/gradle/issues/945