> On 13 Mar 2014, at 6:42, Adam Murdoch <adam.murd...@gradleware.com> wrote: > > >> On 8 Mar 2014, at 1:34 pm, Luke Daley <luke.da...@gradleware.com> wrote: >> >> Hi, >> >> http://issues.gradle.org/browse/GRADLE-2407 >> >> I keep forgetting about this, and would like to fix it. The hack that people >> were using as a workaround >> (http://forums.gradle.org/gradle/topics/any_work_around_in_1_11_for_http_issues_gradle_org_browse_gradle_2407) >> broke in 1.11 due to internal changes. >> >> The problem is that we don’t have a suitable hook to use from an init script >> that is after each project’s buildscript {} is evaluated and before the rest >> of the project configuration is evaluated. >> >> The simplest solution would be to add a new callback hook that fires at the >> right time, but I’m guessing this isn’t going to be palatable. >> >> Does anyone have any ideas for a solution? > > > I think the would be to allow init scripts to inject rules into projects in > the same way that we’re thinking of allowing settings scripts to. > > A work around in the meantime would be to apply the plugin by type rather > than id from the init script, something like: > > initscript { > dependencies { classpath files(… whatever …) } > } > > allprojects { apply plugin: PluginType } > > If using an internal method is ok, you can figure out the type using > plugins.getTypeForId(): > > initscript { > dependencies {… } > } > > def type = gradle.plugins.getTypeForId(‘my-id’) > allprojects { apply plugin: type }
The problem with this is that the classes aren't visible to the project. That's a potentially confusing enough difference that I think it's worth making applying via the project classloader work. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > >
