On May 5, 2009, at 11:21 PM, Adam Murdoch wrote:
Mike wrote:
Adam Murdoch wrote:
What complexities did you run into? I'd like embedding Gradle to
be a
really simple thing to do.
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.
This is good feedback. Can you add some JIRA issues for these?
I think some of the classloader issues could be sorted out when we
merge the settings file into the build file. I'd like to end up with
the Gradle class taking care of pretty much all these issues,
something like:
* 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.
One thing that would also be nice is to extract the command-line
parsing code from the main class. That way you could also use a
command line notation to start Gradle in embedded mode (alternatively
to providing a StartParameter object).
- Hans
On a related note, some other issues that would make gradle easier
to embed:
1) A simplified way of getting all projects, subprojects and tasks.
Currently, I copied and modified the existing mechanism that dumps
the tasks to the console, but that is awkward for just getting a
tree-like, in-memory listing – which most embedded tools would want
access to. This probably also applies to other 'reports' that dump
out to the console such as listing dependencies.
So, something like this on the Gradle class:
Build evaluate();
which would load and evaluate the project tree. From Build, the
entire model is reachable, and we can add convenience methods to it,
if that is needed.
2) A way to skip tasks programmatically. That is, run task X, but
not task Y which X depends on. In particular we'd want to skip
tests, but also other tasks. For example: we have added the concept
of functional tests – which are typically very time-consuming. We
might not want to skip pure unit tests, but do skip functional
tests. Plus, there are also occasions
(usually time-related) where you just want to execute the top level
task and don't want to wait for gradle to determine that the 400
subtasks don't actually need to be performed. This becomes more
apparent in large systems like ours.
This would happen as part of improving skipping from the command-
line (which we plan to do soon-ish, I think).
3) Very minor, but some of the code in BuildExceptionReporter could
made more modular so that others can format gradle errors in the
same way. The formatting of errors there is using the OptionSet
(which seems catered to command lines) as well as assuming that
your using this BuildListener. I ended up copying and pasting much
of that code. Its not a alot of code or complicated, but its
something I think any tool would want access to.
4) Getting access to gradle's output was a little problematic.
Mostly, it was just learning to use Logback, but I'm getting an
oddity where some of the output is duplicated, but not all. I
haven't looked into this much, so I could be using the API
incorrectly, but I thought what I did was fairly straightforward
and this seems like something anyone accessing embedded gradle
would need to do.
What do you need to be able to do here?
Mike
Automated Logic Research Team
--- On Fri, 5/1/09, Adam Murdoch <[email protected]> wrote:
From: Adam Murdoch <[email protected]>
Subject: Re: [gradle-dev] Feedback wanted on Gradle UI for future
Idea plugin
To: [email protected]
Date: Friday, May 1, 2009, 9:09 PM
Mike wrote:
Difficult to answer. This answer relates to
Russel's
previous comment. We don't want to require altering the
gradle
directory. But we've discovered launching gradle has
some complexities.
This is further complicated when used as a plugin.
What complexities did you run into? I'd like embedding
Gradle to be a
really simple thing to do.
At the moment, I'm thinking we're
going to require the
user to specify a gradle installation (on the setup tab),
then we'll
launch each command in a separate VM (which allows you do
fire off
multiple simultaneous commands in a safe manner). An
alternative is to
bundle gradle into the plugin, but I'm not certain how
well that would
work.
Mike
Automated Logic Research Team
--- On Fri, 5/1/09, David Freels <[email protected]>
wrote:
From: David Freels <[email protected]>
Subject: Re: [gradle-dev] Feedback wanted on Gradle UI for
future Idea
plugin
To: [email protected]
Date: Friday, May 1, 2009, 4:47 PM
How
far along is the Idea plug-in?
David Freels
From:
Mike <[email protected]>
To:
[email protected]
Sent: Friday,
May 1, 2009 12:22:30 PM
Subject:
[gradle-dev] Feedback wanted on Gradle UI for future Idea
plugin
We've
made a stand-alone
GUI for gradle
meant to be a foundation for IDE plugins (we specifically
need an
Idea plugin). While not complete, we'd like to get some
initial
feedback on this application. This tool does not use
command line
arguments, but calls Gradle's API directly.
This is very
much a work
in progress
and still has some rough edges. It works against the latest
gradle
trunk (4/29/09).
Here's a link to a
screenshot:
http://www.box.net/shared/teikjcnh8z
(requires cookies).
To try
this out,
download the zip from
http://www.box.net/shared/nlrbrlqqun.
See the
readme.txt file
inside the zip
file.
We have
tested this on
Windows XP,
Ubuntu 8.10 and OS X (Leopard).
Mike
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
