Adam is right, there would be a lot of overlap. I have a working prototype here:
https://github.com/curious-attempt-bunny/gradle/tree/plugin-isolated See: https://github.com/curious-attempt-bunny/gradle/commit/518cdf8700f41d59de5e07c168c0281106c263b6 In fact for your suggestion you would pretty much just need to provide a variation on this: private ClassLoader createIsolatedClassLoader(Configuration configuration, ClassLoader parentClassLoader) { ObservableUrlClassLoader classLoader = new ObservableUrlClassLoader(parentClassLoader); for (File file : configuration.resolve()) { try { classLoader.addURL(file.toURI().toURL()); } catch (MalformedURLException e) { throw new RuntimeException(e); } } return classLoader; } On Sun, Jul 17, 2011 at 11:03 PM, Adam Murdoch <[email protected]> wrote: > > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
