On 20/01/2011, at 12:48 AM, Rene Groeschke wrote: > Hi Dierk, > I am not sure if the groovy/java plugin is the right place for that. What > should the run task do on plain library projects? Maybe a kind of > "application" plugin would fit better.
This is how I would prefer to solve the problem, rather than overloading the language plugins. You'd apply the 'application' plugin, define a main class, and the plugin could: * Add a 'run' task which builds and launches the application with the appropriate configuration. * Add a 'dist' task which builds a zip containing the executable application, with start scripts/executables, runtime dependencies, documentation, etc. It might also build .tgz, a minimal distributions, etc. * Add an 'install' task which installs the application locally. * Configure the IDE plugins to add a run configuration to the project, so you can run the application from the IDE. * Configure the (future) integration test plugin so that an application image is build and made available to the integration tests. * Perhaps auto-detect the main class(es). And so on. There are heaps of places where the simple declaration that 'this is a command-line application' will be really useful. We might specialise this declaration further, into things such as 'server application', so that Gradle can, say, generate the appropriate start/stop script and native wrappers, or into 'gui application', so that Gradle can generate a windows .exe or os x app bundle. -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
