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' 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? On Sat, Jul 16, 2011 at 2:56 PM, cquinn <[email protected]> wrote: > Yes, exactly. I have a single line buildscript entry now for grabbing the > plugin jar from the SCM workspace while I am working out the details of > bootstrapping. Like this: > > buildscript { dependencies { classpath fileTree(dir: > '../../../Tools/nebula/build/libs', include: '*.jar') }} > > But it could get more sophisticated, so I would like to make it centralized > and reusable. I can see wanting to have it setup the classpath > automatically > to get all of our build plugins from a number of possible places, and for > different levels of stabilities. Once the users' build.gradle scripts have > the right buildscript classpath, everything else can be done in the > plugins. > > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/Ideas-for-simplifying-the-bootstrapping-of-plugin-loading-tp4588130p4594982.html > Sent from the gradle-user mailing list archive at Nabble.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
