Hi, As it stands now the scala plugin in the branch is usable and is ready to merged into the gradle trunk (if that is a reasonable temporary location until the plugin repository issue gets resolved?)
The final cleanups I did: - removed the 'scala' configuration - the required scala libraries just get specified on the 'compile' configuration. (I only added the scala configuration after looking at how the groovy plugin worked - I thought it seemed a bit strange at the time). - changed the scalaTools to be transitive - added the 'scala' name in plugins.properties. - updated the branch from the latest trunk. I have listed the future tasks in the existing jira issue ( http://jira.codehaus.org/browse/GRADLE-287). I can remove the defineScalaAnt task in a subsequent pass if the general pattern is to perform the define in each task - the main reason I added the task was to avoid duplicating the definition in each scala task and to avoid the confusion of passing 2 classpaths into the tasks (1 for the compile, 1 for the scala tools, so that the tools do not pollute the compile classpath). It also allows a developer access to other scala ant tasks that are not exposed as gradle tasks (eg scala bazaar) I have not yet read the thread on the plugin repository, but just some initial thoughts about the plugins structure / repository (they might have already been discussed): - provide a plugin to make it easy to build and test a plugin - provide some mechanism to allow versioning of the plugin against the specific version(s) of gradle that it works with Thanks, Ross Is there a way plugins like this can be developed outside the Gradle > tree, i.e. as separate standalone entities. > > Gradle will surely succeed far better if plugins were separate from the > core, there could then be a community of plugins since people could > develop them and use them without having to work with the Gradle source. > > > I agree completely. For know, I'm the only one able to build releases of > our sw locally since I need to use a custom gradle version. Using the > buildSrc is one possible solution, but requires manual updates > > Just an idea: > > Would it be possible to specify a dependency in the buildscript section > and later use it via useplugin? Ie something like > > buildscript { > repositories { > gradlePlugins() > } > dependencies { > classpath 'myniceplugin:stuff:0.7' > } > } > > usePlugin(stuff.MyPlugin) > > > > > You can already do this. > > The piece that's missing from your example above, which would be good to > have, is a central Gradle plugins repository. For now, the plugin author > needs to publish the plugin to a repository somewhere, and advertise the > details to those who want to use the plugin. > > > Adam > >
