GUI

[Steve Appling]

Now that gradlew has been updated, you might try out the GUI tool on gradle
itself.  Run "gradlew --gui".

We would love some more feedback on this tool.
--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tomek Kaczanowski-3]

Hi Steve,

I am sorry to report, that my first try on GUI was rather unsuccessful. :(

I did the following:
a) got the latest version of gradle source from git
b) ./gradlew - everything ok
c) ./gradlew --gui
I got this error (but the UI window has opened):

21:53:27.114 [Thread-4] ERROR o.g.f.i.basic.ProcessLauncherServer -
Starting external process
java.io.IOException: Cannot run program
"/home/tomek/.gradle/wrapper/dists/gradle-0.8-20090916110327+0200/bin/gradle"
(in directory "/home/tomek/work_3rd/gradle"): java.io.IOException:
error=13, Permission denied
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:459)
        at org.gradle.foundation.ipc.basic.ExternalProcess.start(ExternalProcess.java:107)
        at org.gradle.foundation.ipc.basic.ProcessLauncherServer$1.run(ProcessLauncherServer.java:99)
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: java.io.IOException: error=13, Permission denied
        at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
        at java.lang.ProcessImpl.start(ProcessImpl.java:65)
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)
        ... 3 common frames omitted

So I cd to /home/tomek/.gradle/wrapper/dists
chmod -R 755 *

tried once again
./gradlew --gui

no error this time on the stdout, but in the UI window, there is a
message like this:

Completed with errors
and
"Failed to connect to gradle process for command '-t'"

If I click "Refresh" (i click every button possible randomly...)  I
got "error" in the upper window, and in the lower part I get:
Failed to connect to gradle process for command '-t'
Exception in thread "main" java.lang.NoClassDefFoundError:
org/gradle/BootstrapMain
Caused by: java.lang.ClassNotFoundException: org.gradle.BootstrapMain
        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)

Hope it helps in the GUI development.

My environment: Kubuntu 9.04,
------------------------------------------------------------
Gradle 0.8-20090916110327+0200
------------------------------------------------------------

Gradle buildtime: Wednesday, September 16, 2009 11:03:27 AM CEST
Groovy: 1.6.4
Ant: Apache Ant version 1.7.0 compiled on December 13 2006
Ivy: 2.1.0-rc2
Java: 1.6.0_14
JVM: 14.0-b16
JVM Vendor: Sun Microsystems Inc.
OS Name: Linux

--
best regards
Tomek Kaczanowski
http://kaczanowscy.pl/tomek

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[hdockter]

On Sep 16, 2009, at 10:02 PM, Tomek Kaczanowski wrote:

> Hi Steve,
>
> I am sorry to report, that my first try on GUI was rather  
> unsuccessful. :(
>
> I did the following:
> a) got the latest version of gradle source from git
> b) ./gradlew - everything ok
> c) ./gradlew --gui
> I got this error (but the UI window has opened):

I'm not sure if this is related to your problem. The wrapper does not  
contain yet some of the GUI updates Steve has committed recently. I  
will update the wrapper tomorrow.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

>
> 21:53:27.114 [Thread-4] ERROR o.g.f.i.basic.ProcessLauncherServer -
> Starting external process
> java.io.IOException: Cannot run program
> "/home/tomek/.gradle/wrapper/dists/gradle-0.8-20090916110327+0200/
> bin/gradle"
> (in directory "/home/tomek/work_3rd/gradle"): java.io.IOException:
> error=13, Permission denied
>        at java.lang.ProcessBuilder.start(ProcessBuilder.java:459)
>        at org.gradle.foundation.ipc.basic.ExternalProcess.start
> (ExternalProcess.java:107)
>        at org.gradle.foundation.ipc.basic.ProcessLauncherServer$1.run
> (ProcessLauncherServer.java:99)
>        at java.lang.Thread.run(Thread.java:619)
> Caused by: java.io.IOException: java.io.IOException: error=13,  
> Permission denied
>        at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
>        at java.lang.ProcessImpl.start(ProcessImpl.java:65)
>        at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)
>        ... 3 common frames omitted
>
> So I cd to /home/tomek/.gradle/wrapper/dists
> chmod -R 755 *
>
> tried once again
> ./gradlew --gui
>
> no error this time on the stdout, but in the UI window, there is a
> message like this:
>
> Completed with errors
> and
> "Failed to connect to gradle process for command '-t'"
>
> If I click "Refresh" (i click every button possible randomly...)  I
> got "error" in the upper window, and in the lower part I get:
> Failed to connect to gradle process for command '-t'
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/gradle/BootstrapMain
> Caused by: java.lang.ClassNotFoundException: org.gradle.BootstrapMain
> 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)
>
> Hope it helps in the GUI development.
>
> My environment: Kubuntu 9.04,
> ------------------------------------------------------------
> Gradle 0.8-20090916110327+0200
> ------------------------------------------------------------
>
> Gradle buildtime: Wednesday, September 16, 2009 11:03:27 AM CEST
> Groovy: 1.6.4
> Ant: Apache Ant version 1.7.0 compiled on December 13 2006
> Ivy: 2.1.0-rc2
> Java: 1.6.0_14
> JVM: 14.0-b16
> JVM Vendor: Sun Microsystems Inc.
> OS Name: Linux
>
> --
> best regards
> Tomek Kaczanowski
> http://kaczanowscy.pl/tomek
>
> ---------------------------------------------------------------------
> 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

[Mike-655]

--- On Wed, 9/16/09, Tomek Kaczanowski <kaczanowski.tomek@...> wrote:

> From: Tomek Kaczanowski <kaczanowski.tomek@...>
> Subject: Re: [gradle-dev] GUI
> To: dev@...
> Date: Wednesday, September 16, 2009, 8:02 PM
> Hi Steve,
>
> I am sorry to report, that my first try on GUI was rather
> unsuccessful. :(

That's unfortunate. The first issue as you guessed has to do with file permissions. The shell script isn't marked as executable when gradlew expands gradle into your home directory. Its marked as executable in the zip file it downloads, but the unzip process is not preserving it.

>
> I did the following:
> a) got the latest version of gradle source from git
> b) ./gradlew - everything ok
> c) ./gradlew --gui
> I got this error (but the UI window has opened):
>
> 21:53:27.114 [Thread-4] ERROR
> o.g.f.i.basic.ProcessLauncherServer -
> Starting external process
> java.io.IOException: Cannot run program
> "/home/tomek/.gradle/wrapper/dists/gradle-0.8-20090916110327+0200/bin/gradle"
> (in directory "/home/tomek/work_3rd/gradle"):
> java.io.IOException:
> error=13, Permission denied
>         at
> java.lang.ProcessBuilder.start(ProcessBuilder.java:459)
>         at
> org.gradle.foundation.ipc.basic.ExternalProcess.start(ExternalProcess.java:107)
>         at
> org.gradle.foundation.ipc.basic.ProcessLauncherServer$1.run(ProcessLauncherServer.java:99)
>         at
> java.lang.Thread.run(Thread.java:619)
> Caused by: java.io.IOException: java.io.IOException:
> error=13, Permission denied
>         at
> java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
>         at
> java.lang.ProcessImpl.start(ProcessImpl.java:65)
>         at
> java.lang.ProcessBuilder.start(ProcessBuilder.java:452)
>         ... 3 common frames omitted
>
> So I cd to /home/tomek/.gradle/wrapper/dists
> chmod -R 755 *
>
> tried once again
> ./gradlew --gui
>
> no error this time on the stdout, but in the UI window,
> there is a
> message like this:
>
> Completed with errors
> and
> "Failed to connect to gradle process for command '-t'"
>
> If I click "Refresh" (i click every button possible
> randomly...)  I
> got "error" in the upper window, and in the lower part I
> get:
> Failed to connect to gradle process for command '-t'
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/gradle/BootstrapMain
> Caused by: java.lang.ClassNotFoundException:
> org.gradle.BootstrapMain
>     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)
>
> Hope it helps in the GUI development.
>

This sounds like a something is missing. Can you do this: Go to this directory
  /home/tomek/.gradle/wrapper/dists/gradle-0.8-20090916110327+0200

and run
./bin/gradle --gui

Does that yield the same class loader error?

Can you also make an explodedDist of gradle, navigate to [gradle]/build/distributions/exploded and run the above command. Does that yield the class loader error?

> My environment: Kubuntu 9.04,
> ------------------------------------------------------------
> Gradle 0.8-20090916110327+0200
> ------------------------------------------------------------
>
> Gradle buildtime: Wednesday, September 16, 2009 11:03:27 AM
> CEST
> Groovy: 1.6.4
> Ant: Apache Ant version 1.7.0 compiled on December 13 2006
> Ivy: 2.1.0-rc2
> Java: 1.6.0_14
> JVM: 14.0-b16
> JVM Vendor: Sun Microsystems Inc.
> OS Name: Linux
>
> --
> best regards
> Tomek Kaczanowski
> http://kaczanowscy.pl/tomek
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

Mike
Automated Logic Research Team




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[hdockter]

On Sep 16, 2009, at 10:31 PM, Mike wrote:

>
> --- On Wed, 9/16/09, Tomek Kaczanowski <kaczanowski.tomek@...>  
> wrote:
>
>> From: Tomek Kaczanowski <kaczanowski.tomek@...>
>> Subject: Re: [gradle-dev] GUI
>> To: dev@...
>> Date: Wednesday, September 16, 2009, 8:02 PM
>> Hi Steve,
>>
>> I am sorry to report, that my first try on GUI was rather
>> unsuccessful. :(
>
> That's unfortunate. The first issue as you guessed has to do with  
> file permissions. The shell script isn't marked as executable when  
> gradlew expands gradle into your home directory. Its marked as  
> executable in the zip file it downloads, but the unzip process is  
> not preserving it.

Could you file a Jira with fix for 0.8 for that? We need to add some  
logic to the wrapper to fix this.

Thanks

- Hans



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tomek Kaczanowski-3]

Hi Mike,

> This sounds like a something is missing. Can you do this: Go to this directory
>  /home/tomek/.gradle/wrapper/dists/gradle-0.8-20090916110327+0200
> and run
> ./bin/gradle --gui
> Does that yield the same class loader error?
Same error.

> Can you also make an explodedDist of gradle, navigate to [gradle]/build/distributions/exploded and run the above command. Does that yield the class loader error?
./gradlew clean explodedDist
cd build/distributions/exploded/
./bin/gradle --gui
Same error.

--
best regards
Tomek Kaczanowski

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Appling]

Hans Dockter wrote:

>
> On Sep 16, 2009, at 10:02 PM, Tomek Kaczanowski wrote:
>
>> Hi Steve,
>>
>> I am sorry to report, that my first try on GUI was rather
>> unsuccessful. :(
>>
>> I did the following:
>> a) got the latest version of gradle source from git
>> b) ./gradlew - everything ok
>> c) ./gradlew --gui
>> I got this error (but the UI window has opened):
>
> I'm not sure if this is related to your problem. The wrapper does not
> contain yet some of the GUI updates Steve has committed recently. I will
> update the wrapper tomorrow.
>
> - Hans
>

I don't think the updates I made are related to this problem.

Hans and Adam - after correcting the executable permission on the gradle shell
script extracted by gradlew, can you run this? Is anyone else having this
problem?  It seems to work on other Ubuntu machines here (although I haven't
tried on Kubuntu).

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Hans Dockter wrote:

>
> On Sep 16, 2009, at 10:31 PM, Mike wrote:
>
>>
>> --- On Wed, 9/16/09, Tomek Kaczanowski <kaczanowski.tomek@...>
>> wrote:
>>
>>> From: Tomek Kaczanowski <kaczanowski.tomek@...>
>>> Subject: Re: [gradle-dev] GUI
>>> To: dev@...
>>> Date: Wednesday, September 16, 2009, 8:02 PM
>>> Hi Steve,
>>>
>>> I am sorry to report, that my first try on GUI was rather
>>> unsuccessful. :(
>>
>> That's unfortunate. The first issue as you guessed has to do with
>> file permissions. The shell script isn't marked as executable when
>> gradlew expands gradle into your home directory. Its marked as
>> executable in the zip file it downloads, but the unzip process is not
>> preserving it.
>
> Could you file a Jira with fix for 0.8 for that? We need to add some
> logic to the wrapper to fix this.
>

A better solution would be for the UI to not use the scripts.


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Appling]

Adam Murdoch wrote:
>
> A better solution would be for the UI to not use the scripts.
>
>
> Adam
>

We originally were planning to not use them, but if we didn't, we needed to
reproduce the logic that is now in the scripts inside gradle.  We also had our
own internal use case of a custom build script that provides init scripts and
other options.  If we were going to allow the ability to specify a custom script
to run, it seemed best to normally fork by using the built in script.

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Steve Appling wrote:

>
>
> Hans Dockter wrote:
>>
>> On Sep 16, 2009, at 10:02 PM, Tomek Kaczanowski wrote:
>>
>>> Hi Steve,
>>>
>>> I am sorry to report, that my first try on GUI was rather
>>> unsuccessful. :(
>>>
>>> I did the following:
>>> a) got the latest version of gradle source from git
>>> b) ./gradlew - everything ok
>>> c) ./gradlew --gui
>>> I got this error (but the UI window has opened):
>>
>> I'm not sure if this is related to your problem. The wrapper does not
>> contain yet some of the GUI updates Steve has committed recently. I
>> will update the wrapper tomorrow.
>>
>> - Hans
>>
> I don't think the updates I made are related to this problem.
>
> Hans and Adam - after correcting the executable permission on the
> gradle shell script extracted by gradlew, can you run this? Is anyone
> else having this problem?  It seems to work on other Ubuntu machines
> here (although I haven't tried on Kubuntu).
>

This works:
- ./gradlew clean explodedDistBase
- build/distributions/exploded/bin/gradle --gui

This also works:
- chmod +x ~/.gradle/wrapper/dists/gradle-0.8-20090916110327+0200/bin/gradle
- ./gradlew --gui

I'm using a mac.


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Mike-655]

--- On Wed, 9/16/09, Adam Murdoch <a@...> wrote:

> From: Adam Murdoch <a@...>
> Subject: Re: [gradle-dev] GUI
> To: dev@...
> Date: Wednesday, September 16, 2009, 9:02 PM
>
>
> Hans Dockter wrote:
> >
> > On Sep 16, 2009, at 10:31 PM, Mike wrote:
> >
> >>
> >> --- On Wed, 9/16/09, Tomek Kaczanowski <kaczanowski.tomek@...>
> wrote:
> >>
> >>> From: Tomek Kaczanowski <kaczanowski.tomek@...>
> >>> Subject: Re: [gradle-dev] GUI
> >>> To: dev@...
> >>> Date: Wednesday, September 16, 2009, 8:02 PM
> >>> Hi Steve,
> >>>
> >>> I am sorry to report, that my first try on GUI
> was rather
> >>> unsuccessful. :(
> >>
> >> That's unfortunate. The first issue as you guessed
> has to do with file permissions. The shell script isn't
> marked as executable when gradlew expands gradle into your
> home directory. Its marked as executable in the zip file it
> downloads, but the unzip process is not preserving it.
> >
> > Could you file a Jira with fix for 0.8 for that? We
> need to add some logic to the wrapper to fix this.
> >
>
> A better solution would be for the UI to not use the
> scripts.
>
>
> Adam

I agree. We originally tried to go down the path of executing things directly with gradle, but there are several things the gradle-launching scripts are setting up for us and we didn't want to duplicate that information in code and in 2 scripts (for each OS). If this information could be pulled outside of the scripts so that it could be launched via a single java command (which would be the only thing the scripts would do) that would be great. But that might not be practical. There's alot going on in there.

 
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>


Mike
Automated Logic Research Team






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Steve Appling wrote:

>
>
> Adam Murdoch wrote:
>>
>> A better solution would be for the UI to not use the scripts.
>>
>>
>> Adam
>>
>
> We originally were planning to not use them, but if we didn't, we
> needed to reproduce the logic that is now in the scripts inside gradle.

Or move the bits you need into Java. I suspect you only need to worry
about JAVA_HOME, which we know already, and GRADLE_OPTS.

We're going to need to do this for forking Gradle builds.

>   We also had our own internal use case of a custom build script that
> provides init scripts and other options.  If we were going to allow
> the ability to specify a custom script to run, it seemed best to
> normally fork by using the built in script.
>

Needing a custom launcher script sounds like a problem to me. What goes
in the custom script and the init script that couldn't go in the build file?


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[John Murph]

On Wed, Sep 16, 2009 at 5:19 PM, Adam Murdoch <a@...> wrote:

Needing a custom launcher script sounds like a problem to me. What goes in the custom script and the init script that couldn't go in the build file?

Steve was not being very precise.  Our custom script sets the following things:

• JAVA_HOME
• GRADLE_HOME
• --project-dir command line option

It's done this way so that everyone doesn't need to adjust machine wide settings for Java and Gradle when building the project (java and gradle are in our version control so that we all get/share the same versions).  The project dir is set in the script so that we don't need to type it every time we run Gradle.

The GUI doesn't provide the ability to specify all of this right now, so letting users set this kind of stuff up via a custom script seemed best. 

--
John Murph
Automated Logic Research Team

[Mike-655]

--- On Wed, 9/16/09, Tomek Kaczanowski <kaczanowski.tomek@...> wrote:

> From: Tomek Kaczanowski <kaczanowski.tomek@...>
> Subject: Re: [gradle-dev] GUI
> To: dev@...
> Date: Wednesday, September 16, 2009, 8:50 PM
> Hi Mike,
>
> > This sounds like a something is missing. Can you do
> this: Go to this directory
> >
>  /home/tomek/.gradle/wrapper/dists/gradle-0.8-20090916110327+0200
> > and run
> > ./bin/gradle --gui
> > Does that yield the same class loader error?
> Same error.
>
> > Can you also make an explodedDist of gradle, navigate
> to [gradle]/build/distributions/exploded and run the above
> command. Does that yield the class loader error?
> ./gradlew clean explodedDist
> cd build/distributions/exploded/
> ./bin/gradle --gui
> Same error.
>
> --
> best regards
> Tomek Kaczanowski

Its starting to sound like an environment issue. Especially since Adam says its working for him (FYI: I'm on Ubuntu). What do you get when you run "echo $GRADLE_HOME"?
If you get anything, it means we're probably running a different gradle version. But that doesn't make much sense because BootstrapMain has been there for quite some time.

Mike
Automated Logic Research Team






---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

John Murph wrote:

On Wed, Sep 16, 2009 at 5:19 PM, Adam Murdoch <a@...> wrote:

Needing a custom launcher script sounds like a problem to me. What goes in the custom script and the init script that couldn't go in the build file?

Steve was not being very precise.  Our custom script sets the following things:

• JAVA_HOME
• GRADLE_HOME
• --project-dir command line option

It's done this way so that everyone doesn't need to adjust machine wide settings for Java and Gradle when building the project (java and gradle are in our version control so that we all get/share the same versions).  The project dir is set in the script so that we don't need to type it every time we run Gradle.

It seems like you only need a custom script to launch the GUI itself. When the GUI forks Gradle, it should use the Java home and Gradle home it was launched with. It should also honour the --project-dir command-line option, plus a bunch of other command-line options, such as --no-search-upwards, --gradle-user-home, possibly -d, -i, -s, -S.

Then, there's no reason for the GUI to use the custom script to fork Gradle. It can fork Gradle however it likes.


Adam

[Tomek Kaczanowski-3]

Hi Mike,

> Its starting to sound like an environment issue. Especially since Adam says its working for him
> (FYI: I'm on Ubuntu). What do you get when you run "echo $GRADLE_HOME"?
GRADLE_HOME points to /home/tomek/bin/gradle which is a symlink to the
gradle snapshot (a little bit earlier version, Gradle
0.8-20090909213706+0200)

--
best regards
Tomek Kaczanowski

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Appling]

Tomek Kaczanowski wrote:

> Hi Mike,
>
>> Its starting to sound like an environment issue. Especially since Adam says its working for him
>> (FYI: I'm on Ubuntu). What do you get when you run "echo $GRADLE_HOME"?
> GRADLE_HOME points to /home/tomek/bin/gradle which is a symlink to the
> gradle snapshot (a little bit earlier version, Gradle
> 0.8-20090909213706+0200)
>
> --
> best regards
> Tomek Kaczanowski
>

I think that's the problem.  The gradle.bat that is being launched as part of
the GUI forking java is trying to use the wrong gradle.  We can fix this, but
for now try unsetting the GRADLE_HOME and see if that fixes the problem.

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tomek Kaczanowski-3]

Hi Steve,

> I think that's the problem.  The gradle.bat that is being launched as part
> of the GUI forking java is trying to use the wrong gradle.  We can fix this,
> but for now try unsetting the GRADLE_HOME and see if that fixes the problem.
yep, after unsetting GRADLE_HOME i can run the GUI both with
./gradlew --gui
and from the exploded version
without this error.

--
thanks
Tomek Kaczanowski

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email