This was from a discussion on the the dev lists (titled: "Feedback wanted on Gradle UI for future Idea plugin"). Adam Murdock asked me to write up the following as a JIRA issue.

• You only need a gradle-launcher.jar in your classpath

• The Gradle class sets up whatever classloader structure it needs, based on whatever classloader environment it finds itself in, and possibly with some embedding application control over how this looks.

• The Gradle class takes care of setting up logging, based on whatever logging environment it finds itself in, again, with some embedding application control over this. For example, the embedding application could request logging be routed over logback, java util logging, stdout/stderr, or via application provided listeners.

• The Gradle class can optionally run a build in a forked process (and potentially, a long-lived process).

• The Gradle class can optionally run a build using a different version of Gradle.

Here's the original comment that started this:
I was trying to load in Gradle dynamically so you could point the tool to an existing installation. My first problem was that I didn't realize that the logging mechanism (logback) must be loaded using a separate class loader. That was fixed by using the code from BootstrapMain, but then I ran into further class loader issues related to the classes in my GUI tool and gradle. There seems to be some strange stuff going on with classloaders in Gradle (using reflection to change the state variables of system provided class loaders, for instance) that will likely be a problem in the future. However, we will be able to avoid the immediate problems if we launch a separate VM to run gradle commands or if we package all the gradle jars with the tool.