On 17/07/2011, at 9:32 AM, Eric Berry wrote: > I've run into this issue myself. Right now I'm having our developers download > the plugin jar file and install it into gradle lib/plugins directory. But the > buildscript method seems pretty standardized. > > I wonder if it could be automated more by adding something like: > apply plugin: 'company-plugin', fromJar: 'url://to/company-plugin.jar'
We definitely don't want people messing with the lib directory of the Gradle distribution. At some point, we want to switch off the ability to drop things into the lib directory and have them appear on the Gradle classpath. Instead, we want to improve the ways that a build can express its dependencies, and what you've proposed is a good option, I think. > > I was looking through the source recently, and I was thinking it might be > possible to add something like this to the DefaultObjectConfigurationAction. > > Where it would download the jar to ~/.gradle/cache (or somewhere else), and > then add a buildscript closure to the project pointing the dependency at the > downloaded jar file. > > Afterwards applying the plugin. > > I'm not completely familiar with the Gradle source, but is something like > this even feasible? If so, I can try and get something working over the next > week or so and try to submit a patch? It is definitely feasible, and a good idea. A patch would be most welcome (a pull request even more so). The implementation will, however, have a big overlap with the changes Merlyn is proposing that will allow applying dependency artifacts. It would make sense to implement first one, and then the other, otherwise you'll be duplicating a lot of stuff. Perhaps you guys could work together, or alternatively one of you could wait for the other to finish up a patch. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
