This works as designed. (Not saying I'm entirely happy with the design.) To make a library available to build scripts, you can do something like this (in the init script):

rootProject {
buildscript {
dependencies {
classpath ...
}
}
}

For a complete example, see the `customDistribution` sample in the full Gradle distribution. This won't work for applied scripts though. I'm not aware of a way to make it work for applied scripts, other than declaring the dependencies in the applied script itself.

Thanks, this seems a bit better than the class loader hacks I have been doing but one problem is that I would also need to configure the repositories that the init script uses for the build script as well.
I'm not interested in using these dependencies in applied build script (I saw the [other topic]([1]http://forums.gradle.org/gradle/topic...) about this), what I'm trying to do is to initialize some domain objects early before the projects are evaluated, then to set them as extra properties or an extension so that our build plugins can reuse them rather than having to re-create them.
I think what I'm trying to do exactly what the [basic usage of an init script]([2]http://gradle.org/docs/current/usergu...) mentions:
> - Set up enterprise-wide configuration, such as where to find custom plugins.
> - Set up properties based on the current environment, such as a developer's machine vs. a continuous integration server.

But with this limitation, I'm not able to do this kind of setup using custom classes, but must use only standard Gradle/Java types
----------------------------------------------------------------------------------------
[1] http://forums.gradle.org/gradle/topics/how_to_refer_to_classes_on_the_buildscript_classpath_in_an_applied_script
[2] http://gradle.org/docs/current/userguide/init_scripts.html

I don't understand. What's the problem with the solution I posted? Did you have a look at the `customDistribution` sample?

The problem is that I want to execute code before the projects are evaluated, so this code cannot be on the buildscript classpath, but has to be on the init script classpath. On the other hand, this code needs to create and store objects somewhere (Gradle/Project instance) where they can be later accessed by build plugins applied to the projects.

If this cannot be achieved by configuring the init script classpath, can I add this piece of code somewhere else so it becomes part of Gradle and:

*code and objects created by it are visible by init script

*code and objects created by it are visible by build scripts

Unfortunately, I'm not aware of a way to do so.

Ok, while there might be cases where inheriting init script dependencies in the build script classpath might be undesirable (I cannot think of such right now), I think that it is more common to assume that if something is declared as a dependency in the init script, it would be available for the build scripts as well.
Also, would not this also solve GRADLE-2407([1]http://issues.gradle.org/browse/GRADL...)?
----------------------------------------------------------------------------------------
[1] http://issues.gradle.org/browse/GRADLE-2407

In larger builds, a global script class path can cause version conflict problems. Nevertheless I consider it necessary to have a way to globally share dependencies between all scripts in a build. I'll create an issue, let's see where it goes.

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!

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.