[GRADLE-480] Improve launching gradle for tool purposes Created: 14/May/09  Updated: 04/Jan/13  Resolved: 09/Nov/11

Status: Resolved
Project: Gradle
Affects Version/s: 0.5.2
Fix Version/s: 1.0-milestone-3

Type: Improvement
Reporter: Mike Assignee: Unassigned
Resolution: Fixed Votes: 0

Issue Links:
Related to GRADLE-608 Make it easier to receive logging out... Resolved


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.

Comment by Adam Murdoch [ 26/Sep/09 ]

0.8 will address some of the issues here:

  • You don't need a separate classloader for the logging mechanism. It can live in the same classloader as the rest of the Gradle libs.
  • Gradle doesn't mess with the system class loaders any more.
  • You can attach a simple listener to GradleLauncher to receive stdout or stderr logging without needing to do anything with logback.
Comment by Adam Murdoch [ 09/Nov/11 ]

The tooling api addresses these issues.

Generated at Wed Jun 30 11:31:11 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.