Feedback wanted on Gradle UI for future Idea plugin
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
|
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
by Adam Murdoch-2
::
Rate this Message:
Steve Appling wrote: > > > Adam Murdoch wrote: >> * There doesn't seem to be a way to run a particular task for the >> selected project and all its subprojects. For example, I can't do the >> equivalent of 'gradle libs' from the root of the java multiproject >> sample. >> > Good point - what would be appropriate here, the set of all unique > task names from all subprojects? > I'm not sure. Sometimes you want to run a given task recursively, and sometimes non-recursively. You need some way to let the UI know your intention. Different tabs? A recursive mode checkbox? >> >> * Logging in the output window should default to the same level as >> when you run Gradle from the command-line >> > Perhaps it would be OK to just default to this. I would like to be > able to change this without having to re-launch the application. > Would you want to do this while a build is running? Or retrospectively, so that the logging level is more of a filter over the console output? Adam --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
by Adam Murdoch-2
::
Rate this Message:
Mike wrote: Adam, In response to Perhaps this message should be treated as part of the textual output of the build, rather than part of the embedding application. Number 4 is related to how to latch onto gradle's current textual output and showing it as the output occurs. Essentially, this amounts to adding a Logback appender (which is what I did), but I'm getting some lines duplicated, but most are working correctly. While I might have a bug in my code causing the duplicates, it concerns me that such a simple thing is susceptible to such a bug. Do you know what's being duplicated? eg a particular log level? a particular category? messages from Gradle itself, or redirected ivy, ant or stdout messages? It seems like any tool would need access to gradle's output, and since this is used for tracking down build problems, it needs to be highly accurate. I would prefer to add an output listener to gradle that just hands the text back to me (as it occurs), shielding me from the details of Logback. How would you like this to look? Some options: * You provide a Writer which receives the text which would be written to stdout/stderr as a stream of text. Perhaps separate Writers for stdout and stderr. * You provide a listener which receives each log message as a String, possibly with some meta-info like severity and category. * You provide an slf4j Logger, or java.util.Logger, or logback Appender, or ... Adam |
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
by Adam Murdoch-2
::
Rate this Message:
Mike wrote: Adam wrote: In the java multiproject sample, the :services project doesn't do anything, but it has a bunch of tasks. I wanted to hide the :services project, but keep the :services:webapplication project visible. As in, I wanted to say something like: don't show me empty intermediate projects. Adam |
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
by hdockter
::
Rate this Message:
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 <a@...> wrote: >> >> >>> From: Adam Murdoch <a@...> >>> Subject: Re: [gradle-dev] Feedback wanted on Gradle UI for future >>> Idea plugin >>> To: dev@... >>> 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 <dafreels@...> >>> wrote: >>> >>> >>> >>> From: David Freels <dafreels@...> >>> >>> Subject: Re: [gradle-dev] Feedback wanted on Gradle UI for >>> future Idea >>> plugin >>> >>> To: dev@... >>> >>> Date: Friday, May 1, 2009, 4:47 PM >>> >>> >>> >>> >>> >>> How >>> far along is the Idea plug-in? >>> >>> >>> David Freels >>> >>> >>> >>> >>> >>> >>> From: >>> Mike <alc.mike@...> >>> >>> To: >>> dev@... >>> >>> 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 |
|
|
|
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
