|
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 |
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Mike,
On Fri, 2009-05-01 at 09:22 -0700, Mike wrote:
> 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).
>
I am not convinced it is correct to require people to put the GradleUI
jar in their Gradle installation. Much better would be to allow this
but also to use GRADLE_HOME to find it from wherever GradleUI is
installed. My reasoning here is that I want to be able to remove and
replace my Gradle installation and I don't want to remember to have to
reinstall the GradleUI every time.
I wonder if taking the groovy starter script as a basis for a gradleui
script is a bad idea?
You may want to take a look at the Gant scripts for ideas?
--
Russel.
============================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip: russel.winder@...
London SW11 1EN, UK. m: +44 7770 465 077 xmpp: russel@...
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Sorry, I forgot to add my data point to show that hardwiring the
location of the gradleui.jar is a bad move.
|> sh -x ~/bin/gradleui
+ GRADLE_APP_NAME=Gradle
+ MAX_FD=maximum
+ cygwin=false
+ msys=false
+ darwin=false
+ uname
+ [ -z /usr/lib/jvm/java-6-sun-1.6.0.13 ]
+ false
+ [ -z /home/users/russel/lib/Java/gradle -o ! -d /home/users/russel/lib/Java/gradle ]
+ CLASSPATH=/home/users/russel/lib/Java/gradle/lib/gradleui.jar
+ [ -z ]
+ [ -n /usr/lib/jvm/java-6-sun-1.6.0.13 ]
+ [ -x /usr/lib/jvm/java-6-sun-1.6.0.13/jre/sh/java ]
+ JAVACMD=/usr/lib/jvm/java-6-sun-1.6.0.13/bin/java
+ [ ! -x /usr/lib/jvm/java-6-sun-1.6.0.13/bin/java ]
+ [ -z /usr/lib/jvm/java-6-sun-1.6.0.13 ]
+ [ false = false -a false = false ]
+ ulimit -H -n
+ MAX_FD_LIMIT=1024
+ [ 0 -eq 0 ]
+ [ maximum = maximum -o maximum = max ]
+ MAX_FD=1024
+ ulimit -n 1024
+ [ 0 -ne 0 ]
+ useprofiler=false
+ [ != ]
+ TOOLS_JAR=/usr/lib/jvm/java-6-sun-1.6.0.13/lib/tools.jar
+ false
+ false
+ STARTER_MAIN_CLASS=com.controlj.gradleplugin.userinterface.graphical.ApplicationBootstrap
+ false
+ exec /usr/lib/jvm/java-6-sun-1.6.0.13/bin/java -classpath /home/users/russel/lib/Java/gradle/lib/gradleui.jar -Dgradle.home=/home/users/russel/lib/Java/gradle -Dtools.jar=/usr/lib/jvm/java-6-sun-1.6.0.13/lib/tools.jar com.controlj.gradleplugin.userinterface.graphical.ApplicationBootstrap
Exception in thread "main" java.lang.NoClassDefFoundError: com/controlj/gradleplugin/userinterface/graphical/ApplicationBootstrap
Caused by: java.lang.ClassNotFoundException: com.controlj.gradleplugin.userinterface.graphical.ApplicationBootstrap
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class: com.controlj.gradleplugin.userinterface.graphical.ApplicationBootstrap. Program will exit.
--
Russel.
============================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip: russel.winder@...
London SW11 1EN, UK. m: +44 7770 465 077 xmpp: russel@...
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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 |
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Mike,
On Fri, 2009-05-01 at 09:22 -0700, Mike wrote:
> 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).
Using the UI standalone in a Java Jar project, I got:
Build failed with an exception.
Settings file '/home/users/russel/Repositories/Bazaar/Masters/ADS/settings.gradle'
A problem occurred evaluating the settings file.
Cause: /home/users/russel/Repositories/Bazaar/Masters/ADS/gradle-imports (No such file or directory)
Exception is:org.gradle.initialization.ScriptEvaluatingSettingsProcessor.applySettingsScript(ScriptEvaluatingSettingsProcessor.java:84)
org.gradle.initialization.ScriptEvaluatingSettingsProcessor.process(ScriptEvaluatingSettingsProcessor.java:66)
org.gradle.initialization.PropertiesLoadingSettingsProcessor.process(PropertiesLoadingSettingsProcessor.java:31)
org.gradle.initialization.ScriptLocatingSettingsProcessor.process(ScriptLocatingSettingsProcessor.java:34)
org.gradle.Gradle.loadSettings(Gradle.java:133)
org.gradle.Gradle.run(Gradle.java:92)
com.controlj.gradle.foundation.gradledirect.GradleHelper.runGradleRecordStandardOutput(GradleHelper.java:429)
com.controlj.gradle.foundation.gradledirect.GradleHelper.refreshProjectsAndTasks(GradleHelper.java:156)
com.controlj.gradleplugin.foundation.GradlePluginLord.refreshProjectsAndTasks(GradlePluginLord.java:124)
com.controlj.gradleplugin.userinterface.graphical.SwingGradleWrapper$4.construct(SwingGradleWrapper.java:193)
com.controlj.green.common.SwingWorker$2.run(SwingWorker.java:209)
java.lang.Thread.run(Thread.java:619)
So I guess there are assumptions about what structures are available and
the context they are in?
--
Russel.
============================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip: russel.winder@...
London SW11 1EN, UK. m: +44 7770 465 077 xmpp: russel@...
|
|
 Re: Feedback wanted on Gradle UI for future Idea plugin
Utlimately, you are correct. This was just a first pass at getting things to work. I actually ran into quite a bit of difficulty getting things to run properly. So this was a temporary solution. This is just to get some feedback for now.
Mike
Automated Logic Research Team
--- On Fri, 5/1/09, Russel Winder <russel.winder@...> wrote:
From: Russel Winder <russel.winder@...>
Subject: Re: [gradle-dev] Feedback wanted on Gradle UI for future Idea plugin
To: dev@...
Date: Friday, May 1, 2009, 4:43 PM
Mike, On Fri, 2009-05-01 at 09:22 -0700, Mike wrote: > 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). > I am not convinced it is correct to require people to put the GradleUI jar in their Gradle
installation. Much better would be to allow this but also to use GRADLE_HOME to find it from wherever GradleUI is installed. My reasoning here is that I want to be able to remove and replace my Gradle installation and I don't want to remember to have to reinstall the GradleUI every time. I wonder if taking the groovy starter script as a basis for a gradleui script is a bad idea? You may want to take a look at the Gant scripts for ideas? -- Russel. ============================================================ Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 voip: sip: russel.winder@...London SW11 1EN, UK. m: +44 7770 465 077 xmpp: russel@...
|
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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. 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 |
|
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
I've seen this error if I'm NOT running the plugin from the gradle directory. It has to do with gradle's working directory. Based on your path, it looks like your running it from your project's directory. On Linux (it looks like that's what you're running), go to the gradle directory and do ".\bin\gradleui" to launch the UI. The error is because gradle is looking for gradle-imports.
There shouldn't be an context or structure issues for the UI itself, however, I haven't quite overcome some of the pathing issues with gradle. It seems to want things setup very specifically. Or I could just doing someting horribly incorrect. This is something that will definitely be corrected.
Mike
Automated Logic Research Team
--- On Fri, 5/1/09, Russel Winder <russel.winder@...> wrote:
From: Russel Winder <russel.winder@...>
Subject: Re: [gradle-dev] Feedback wanted on Gradle UI for future Idea plugin
To: dev@...
Date: Friday, May 1, 2009, 4:54 PM
Mike, On Fri, 2009-05-01 at 09:22 -0700, Mike wrote: > 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). Using the UI standalone in a Java Jar project, I got: Build failed with an exception. Settings file '/home/users/russel/Repositories/Bazaar/Masters/ADS/settings.gradle' A problem occurred evaluating the settings file. Cause: /home/users/russel/Repositories/Bazaar/Masters/ADS/gradle-imports (No such file or directory) Exception is:org.gradle.initialization.ScriptEvaluatingSettingsProcessor.applySettingsScript(ScriptEvaluatingSettingsProcessor.java:84) org.gradle.initialization.ScriptEvaluatingSettingsProcessor.process(ScriptEvaluatingSettingsProcessor.java:66)
org.gradle.initialization.PropertiesLoadingSettingsProcessor.process(PropertiesLoadingSettingsProcessor.java:31) org.gradle.initialization.ScriptLocatingSettingsProcessor.process(ScriptLocatingSettingsProcessor.java:34) org.gradle.Gradle..loadSettings(Gradle.java:133) org.gradle.Gradle.run(Gradle.java:92) com.controlj.gradle..foundation.gradledirect.GradleHelper.runGradleRecordStandardOutput(GradleHelper.java:429) com.controlj.gradle.foundation.gradledirect.GradleHelper.refreshProjectsAndTasks(GradleHelper.java:156) com.controlj.gradleplugin.foundation.GradlePluginLord.refreshProjectsAndTasks(GradlePluginLord.java:124) com.controlj.gradleplugin.userinterface.graphical.SwingGradleWrapper$4.construct(SwingGradleWrapper.java:193)
com.controlj.green.common.SwingWorker$2.run(SwingWorker.java:209) java.lang.Thread.run(Thread.java:619) So I guess there are assumptions about what structures are available and the context they are in? -- Russel. ============================================================ Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 voip: sip: russel.winder@...London SW11 1EN, UK. m: +44 7770 465 077 xmpp: russel@...
|
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Mike,
On Fri, 2009-05-01 at 10:42 -0700, Mike wrote:
> I've seen this error if I'm NOT running the plugin from the gradle
> directory. It has to do with gradle's working directory. Based on your
> path, it looks like your running it from your project's directory. On
> Linux (it looks like that's what you're running), go to the gradle
> directory and do ".\bin\gradleui" to launch the UI. The error is
> because gradle is looking for gradle-imports.
> There shouldn't be an context or structure issues for the UI itself,
> however, I haven't quite overcome some of the pathing issues with
> gradle. It seems to want things setup very specifically. Or I could
> just doing someting horribly incorrect. This is something that will
> definitely be corrected.
>
> Mike
> Automated Logic Research Team
>
Aha, well spotted on all counts :-)
I tried starting in $GRADLE_HOME and things were far more "working":
:: loading settings :: url = jar:file:/home/users/russel/lib/Java/gradle/lib/ivy-2.1.0-rc1.jar!/org/apache/ivy/core/settings/ivysettings.xml
:: resolving dependencies :: org.gradle#build;SNAPSHOT
confs: [build]
:: resolution report :: resolve 40ms :: artifacts dl 0ms
---------------------------------------------------------------------
| | modules || artifacts |
| conf | number| search|dwnlded|evicted|| number|dwnlded|
---------------------------------------------------------------------
| build | 0 | 0 | 0 | 0 || 0 | 0 |
---------------------------------------------------------------------
Build failed with an exception.
Use the stack trace options to get more details
Build file '/home/users/russel/Repositories/Bazaar/Masters/ADS/build.gradle' line: 48
A problem occurred evaluating root project 'ADS'.
Cause: Configuration with name 'providedCompile' not found.
This is a Gradle Trunk problem, not a problem with Gradle UI.
That's about all I can do for now I'm afraid.
--
Russel.
============================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip: russel.winder@...
London SW11 1EN, UK. m: +44 7770 465 077 xmpp: russel@...
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Mike wrote:
> 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
>
While we originally started development of this as an IDEA plugin, I think it
would actually be very useful just as a GUI for Gradle. I'm not aware of
another build tool that has something like this, but Git has something similar
(git gui). I would love to be able to run gradle --interactive to launch this.
Again, Mike did this with the extra launcher script just as a quick way to
solve some issues so that we could get some early feedback - that is not
intended to be how it will work in the end.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Steve,
On Fri, 2009-05-01 at 14:04 -0400, Steve Appling wrote:
[ . . . ]
> While we originally started development of this as an IDEA plugin, I think it
> would actually be very useful just as a GUI for Gradle. I'm not aware of
> another build tool that has something like this, but Git has something similar
> (git gui). I would love to be able to run gradle --interactive to launch this.
> Again, Mike did this with the extra launcher script just as a quick way to
> solve some issues so that we could get some early feedback - that is not
> intended to be how it will work in the end.
No problem. It is invariably more important to get stuff out for people
to tinker with than to try and get something right before issuing it.
Even if some comments are about the wrong stuff, getting the comments
flowing creates the energy that fosters real progress.
I think Bazaar/Mercurial/Git are bad analogues since they are VCSs and
the use cases have very different aims. The real analogues are SCons,
Waf, etc. I don't think any of these are anything other than
commandline. I don't know of GUIs for these but there is an Eclipse
plugin for SCons I think.
The question is what benefit does a GUI bring over command line. On
Windows this is probably more of an issue as the concept of command line
seems to be anathema -- though I see PowerShell is making moves towards
popularity. Having said this I think Windows in anathema an use only
Ubuntu, Mac OS X and Solaris ;-)
It might be worth trying to do the GUI design based on a HCI UI design
analysis.
--
Russel.
============================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip: russel.winder@...
London SW11 1EN, UK. m: +44 7770 465 077 xmpp: russel@...
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Russel Winder wrote:
> No problem. It is invariably more important to get stuff out for people
> to tinker with than to try and get something right before issuing it.
> Even if some comments are about the wrong stuff, getting the comments
> flowing creates the energy that fosters real progress.
>
> I think Bazaar/Mercurial/Git are bad analogues since they are VCSs and
> the use cases have very different aims. The real analogues are SCons,
> Waf, etc. I don't think any of these are anything other than
> commandline. I don't know of GUIs for these but there is an Eclipse
> plugin for SCons I think.
>
> The question is what benefit does a GUI bring over command line. On
> Windows this is probably more of an issue as the concept of command line
> seems to be anathema -- though I see PowerShell is making moves towards
> popularity. Having said this I think Windows in anathema an use only
> Ubuntu, Mac OS X and Solaris ;-)
>
I think that there are a lot of cases where having a GUI can be an advantage,
particularly when there is a lot of information involved.
We are working on a very big build and sometimes I find it easier to see a tree
based view of my projects and tasks than to always type them on the command
line. "gradle -t" currently outputs 2,488 lines for our system. I find it much
easier to use a GUI tree of projects and tasks to find anything uncommon than to
try to try to find the right task via the command line.
I also find it advantageous to keep a favorites list of tasks or to filter out
tasks that I know I won't use often. Configuring this type of thing is often
easier with a GUI.
Coming from a Windows world, I just find it useful to have the build output go
into a scrollable (and soon searchable) window. Running from a DOS shell, I
sometimes miss information because it scrolled off the top of the buffer. I even
find little things like having the timestamp of the output results show up in
the header of the output window very helpful.
While Mike didn't mention it, he architected this to allow plugins to this GUI
to contribute more tabs. We have considered ideas like a tree view of the
dependency or task reports (instead of the ascii art text view). I'm sure there
are a lot of other useful things others could contribute.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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 |
|
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
On Fri, 01 May 2009 14:04 -0400, "Steve Appling" < sajakarta@...>
wrote:
>
>
> Mike wrote:
> > 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
> >
>
> While we originally started development of this as an IDEA plugin, I
> think it
> would actually be very useful just as a GUI for Gradle. I'm not aware of
> another build tool that has something like this, but Git has something
> similar
> (git gui). I would love to be able to run gradle --interactive to launch
> this.
> Again, Mike did this with the extra launcher script just as a quick way
> to
> solve some issues so that we could get some early feedback - that is not
> intended to be how it will work in the end.
We have talked about this quite a while ago that it would be cool to
have a stand alone GUI runner. I'm excited that this is now going to
happen. This has a lot of potential. For example better progress
reporting (in particular for future multi-threaded builds), minimal
startup time, structured view, .... And of course it is a perfect base
for any IDE plugin (although for Eclipse you would need SWT).
Anyhow, excellent news
Thanks
- Hans
>
>
>
> --
> Steve Appling
> Automated Logic Research Team
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
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 < 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
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Mike wrote:
> 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).
>
>
<clip>
Some people had trouble running the previous demo. At Hans' suggestion we made
a demonstration gradle distribution that incorporates the GUI. You can download
it from http://www.box.net/shared/31lox0chou.
Run "gradle --gui" in your project build directory using the version of gradle
in this distribution. You can try using it from the samples/java/multiproject
directory for a start.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Hi,
This looks great. Do you plan to keep it as a standalone UI once the IDE
plugins are done?
I have some comments (though I guess the answer to most is that you just
haven't gotten around to it yet)
* 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.
* There doesn't seem to be a way to run the default tasks, or to see
what they are.
* Logging in the output window should default to the same level as when
you run Gradle from the command-line
* I had trouble getting the project filters to work, for example, when I
hid :services but left :services:webservice shown.
* What would you use favourites for? Is there something missing from the
build file, such that you can declare this (or some of it) in the build
file instead, and thereby share it with everyone?
Steve Appling wrote:
>
>
> Mike wrote:
>> 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).
>>
>>
> <clip>
>
> Some people had trouble running the previous demo. At Hans'
> suggestion we made a demonstration gradle distribution that
> incorporates the GUI. You can download it from
> http://www.box.net/shared/31lox0chou.
>
> Run "gradle --gui" in your project build directory using the version
> of gradle in this distribution. You can try using it from the
> samples/java/multiproject directory for a start.
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
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 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
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Adam Murdoch wrote:
> Hi,
>
> This looks great. Do you plan to keep it as a standalone UI once the IDE
> plugins are done?
>
Yes, I personally think this is useful outside of the IDE (helps with
startup/config time for big systems among other things).
> I have some comments (though I guess the answer to most is that you just
> haven't gotten around to it yet)
All comments are welcome, but you are right - this is very early and we really
just wanted feedback on the concept of having a GUI like this. We have our own
long internal list of both wants and bugs.
>
> * 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?
> * There doesn't seem to be a way to run the default tasks, or to see
> what they are.
I think the default task for a project should in bold, but you should perhaps
also be able to run it from the project level. Currently double-clicking the
project just expands the tree, but perhaps it should run the default task instead.
>
> * 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.
> * I had trouble getting the project filters to work, for example, when I
> hid :services but left :services:webservice shown.
You're right, there are some bugs with this.
>
> * What would you use favourites for? Is there something missing from the
> build file, such that you can declare this (or some of it) in the build
> file instead, and thereby share it with everyone?
>
I have found that there are a handful of tasks that I use frequently and this is
a great way to save those in a convenient place. Each person on a project who
has a different role may end up with different list, but this way they can
configure it themselves.
Although it doesn't handle this yet, we intend to allow the favorites to support
other command line options and multiple tasks. This provides a way of handling
all the aliased commands people might typically configure for themselves (like
the ones Hans listed on
http://docs.codehaus.org/display/GRADLE/Developer%27s+Builds).
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|
|
Re: Feedback wanted on Gradle UI for future Idea plugin
Adam, In response to
>>> 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?
Number 3 and 4 are related to the fact that I'm trying to show the same output that 'command line' gradle shows (in the lower window). This is useful (or the only) information for tracking down problems in the build process.
For number 3: If an exception occurs that causes the build to fail, I want to report it in the same manner gradle does. This is more than just Exception.getMessage(). There's logic for determining your 'stacktrace level' and calling StackTraceUtils.deepSanitize() as well as a check for GradleScriptException explicitly. Not a ton of functionality, but something that any tool would be duplicating and could potentially get out of synch.
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. 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.
With both of these, my real concern is that any tool would need this in an accurate manner.
Mike
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
|
signature.asc (204 bytes) 
