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.
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
