Very cool. I'll check it out. Thanks very much. :) On Mon, Jul 18, 2011 at 8:46 AM, Merlyn Albery-Speyer < [email protected]> wrote:
> 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 > > > -- Learn from the past. Live in the present. Plan for the future. Blog: http://eric-berry.blogspot.com jEdit <http://www.jedit.org> - Programmer's Text Editor Bazaar <http://bazaar.canonical.com> - Version Control for Humans
