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