I think Gradle should have a tomcat plugin in addition to the jetty one. tomcat is more popular and jetty has been made overly complex by eclipse (big surprise). possibly use this one: https://github.com/bmuschko/gradle-tomcat-plugin
I would also note that a co-worker commented that gradle was “immature” in not having a tomcat plugin as further evidence we should be using gradle.
Is there something the tomcat plugin doesn’t do that you need? I think it’s a drop in replacement for the jetty plugin and does everything it does. The author has been historically very good at fixing issues and ensuring compatability.
In case you guys decide to pull it into Gradle core I’d be happy to make this happen. Either way I will make sure feature requests get implemented and potential bugs fixed.
The Jetty plugin only supports one specific version of Jetty as Gradle core provides its dependencies so there’s no way to switch between versions. The Tomcat plugin supports the version you specify based on your configuration. Even if the Tomcat plugin would be moved into Gradle core you’d have to define its dependencies as it would cause classloading issues otherwise if you would mix them up.
This is a general issue with Gradle plugins at the moment as there is no way to define a plugin’s dependencies in a descriptor.
I’m not familiar with the issue you are referring to. That is, I’m not aware of any issues with resolving transitive dependencies of plugins. Can you provide some more info?
Maybe I didn’t communicate this correctly. There’s no problem with resolving transitive dependencies of plugins. The issue I am referring to is the fact that the Jetty plugin gets its dependencies provides by Gradle core (lib/plugins). In case you’d move the Tomcat plugin into Gradle Phil would like its dependencies to be provided by Gradle as well and not declaratively by a custom configuration. Jetty’s dependencies would clash with the ones needed by the Tomcat plugin e.g. the JSP API version.
In terms of Gradle plugins I am referring to feature requests that I would like to see e.g. that plugins should declare its dependencies in a descriptor like Grails does it for example. It would be great if the user wouldn’t have to declare this if they don’t want to. I will put together my ideas and thoughts in a new post soon.
I was thinking more down the line of Hans’ posting about a plugin portal and the support for plugins in general: http://forums.gradle.org/gradle/topics/plugin_portal_improving_plugin_development. It’s great to see it on the roadmap and I am looking forward to the result. One more think that I think should be addressed is classloading isolation for plugins.