[GRADLE-2628] Allow build script classpath to be adjusted in script loaded via "apply from" Created: 11/Jan/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.3
Fix Version/s: None

Type: Improvement
Reporter: Peter Horvath Assignee: Unassigned
Resolution: Won't Fix Votes: 3


 Description   

We have a central build script, which defines re-usable task etc configurations, including plugins.

At the moment Gradle doesn't allow the script included via "apply from" to modify the classpath.

Example of the desired setup:

There would be one master build file, which can be re-used. It would contain all declarations, classpath settings required, including classpath settings required for plugins like the following:

MasterBuild.gradle
buildscript {
	dependencies {
		classpath files(
			'a/b/c/foo.jar',
			'a/b/c/bar.jar'
		)
	}
}


...

task commonOperations << { 

...

 }

...

This master build file would be the included in a number of build scripts that re-use operations defined in the master build script without having to define anything else.

build.gradle
apply from: ".../ACME/MasterBuild.gradle"

At the moment this is not possible since Gradle does not allow the build script classpath to be adjusted in an imported file.
This means build scripts loading MasterBuild.gradle using apply from directive still have to set the classpath for plugins in the build file, leading to code duplication:

Current work around:

build.gradle
buildscript {
	dependencies {
		classpath files(
			'a/b/c/foo.jar',
			'a/b/c/bar.jar'
		)
	}
}

apply from: ".../ACME/MasterBuild.gradle"


 Comments   
Comment by Andre Kelpe [ 19/Jul/13 ]

The approach you describe works for me as long as you only use tasks from the referenced jars. If you try to do an "apply plugin:" from within those jars, it does not work. This must be a classloader issue, I guess, but nontheless, would it be great, to have this capability.

Comment by Adam Kaufman [ 15/Jan/14 ]

For what it's worth, I'm still running up against this in 1.10 (cannot apply a custom plugin from within an external script). I would love to see this functionality become available as I have several instances in which I'd like to use it.

Comment by Adam Kaufman [ 25/Sep/15 ]

We're up to 2.6, and this remains a significant problem for us. We have a system of shared build scripts that we use across dozens of projects in order to promote standards and reduce boilerplate. We use a number of plugins, some of which require resolution from our local maven repository, and due to the issue presented in this ticket we cannot share the buildscript components necessary to initialize those plugins. This has led to quite a bit of boilerplate copy-pasting from project to project which is difficult to maintain when changes arise, nevermind making the build scripts less focused and more difficult to read.

The new plugins block functionality seemed promising at first, but we cannot use it as a solution in our situation. We have a central init script (used in an apply from statement) which contains both buildscript elements, and statements outside of any buildscript block. If we put the plugins block before the init script, the init script fails, and if we do the reverse, the plugins block fails. It seems that the only way out of this is to have this classpath issue addressed. Please help!

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:27:07 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.