Allowing init scripts to apply custom plugins (GRADLE-2407)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Allowing init scripts to apply custom plugins (GRADLE-2407)

Luke Daley-2
Hi,


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?
Reply | Threaded
Open this post in threaded view
|

Re: Allowing init scripts to apply custom plugins (GRADLE-2407)

Adam Murdoch

On 8 Mar 2014, at 1:34 pm, Luke Daley <[hidden email]> wrote:

Hi,


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 }


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: Allowing init scripts to apply custom plugins (GRADLE-2407)

Luke Daley-2


On 13 Mar 2014, at 6:42, Adam Murdoch <[hidden email]> wrote:


On 8 Mar 2014, at 1:34 pm, Luke Daley <[hidden email]> wrote:

Hi,


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



Reply | Threaded
Open this post in threaded view
|

Re: Allowing init scripts to apply custom plugins (GRADLE-2407)

Adam Murdoch

On 13 Mar 2014, at 6:55 am, Luke Daley <[hidden email]> wrote:



On 13 Mar 2014, at 6:42, Adam Murdoch <[hidden email]> wrote:


On 8 Mar 2014, at 1:34 pm, Luke Daley <[hidden email]> wrote:

Hi,


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.

It depends on the plugin. It sounds like this will work just fine for the use case in the issue.

Let’s get the plugin DSL working instead.

--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com