Hi Hans,
On Mon, Oct 6, 2008 at 4:26 PM, Hans Dockter <[EMAIL PROTECTED]> wrote:
>
> On Oct 6, 2008, at 3:32 PM, Victor Ott wrote:
[...]
> I had been confused by this as well. This config.xml is one way to configure
> how launch4j _generates_ the gradle.exe at build time.
Yes, and I suppose the issue is there, in the way "gradle.exe" was
generated. Those properties can't be overridden at runtime, at least
according to the docs:
"When you create a wrapper or launcher all configuration details are
compiled into the executable and cannot be changed without recreating
it or hacking with a resource editor."
That's why I was looking for that file, and strongly expected it to be
in the SVN repository(!?). Without it, Launch4J config must be done
from scratch.
>> Wanting to switch to 0.4 Gralde *TODAY*, I finally hacked up a tiny
>> .CMD script (I hate .BAT, and Win9x is obsolete), inpired by the Un*x
>> script from the bin directory. It's small and stupid, but why do more
>> than necessary? Here it is, maybe someone else could use it too:
>
> I share your opinion on Win9x. After all, those niche users would be able to
> run Gradle via cygwin.
>
> What is the advantage of cmd over bat? Unfortunately I guess it does not
> solve our main problem.
CMD scripts (since WinNT4) have a extended syntax compared to the
crippled BAT (e.g. more complex for loops, code blocks, etc), and are
mostly backwards compatible with BAT. The features are not on SH/BASH
level, but better than before.
No, my script is _not a solution_, only a quick workaround.
> If you call 'cmd /c gradle.exe' it returns 1 if the
> build fails. If you call 'cmd /c gradle.cmd' it returns 0 in case of a
> failing build, as far as I can tell. Therefore Teamcity and Bamboo would not
> recognize this build as failed.
> On the other hand we can't leave things as they are. One approach might be
> to provide again a bat or cmd script and drop launch4j, and additionally
> focusing of providing Gradle plugins for Teamcity and Bamboo. Another
> approach would be to provide .exe and .cmd files.
I've added a last line to my script, right after the JAVACMD call:
"echo return code: %ERRORLEVEL%" and the value returned by java.exe is
always "0", even when the build fails!?
============================
Execution failed for task :ZZZZZZZZZZZ:compile.
Cause: Not all dependencies could be resolved!
BUILD FAILED
Total time: 7.321 secs
return code: 0 <<< !?!?
============================
Looks to me like class org.gradle.BootstrapMain (which is started by
my script) doesn't return a code different from 0 on errors...
Hmmmm, does org.gradle.BootstrapMain end with "return" or with
"System.exit(X)"? Only System.exit() returns a code to the caller
process, main() has void return type.
Victor
PS
As PoC I've forced a Gradle error early by calling with conflicting
arguments: "gradle.cmd -i -j " [Btw, Gradle returns code 0 on invalid
arguments... Main.main() line 115, should be System.exit(1) or so].
The result is:
==========
D:\xyz\Prj>gradle.cmd -i -j
[...]
Error: For the dependency output you must either set -i or -j. Not Both!
return code: 1
D:\xyz\Prj>echo %ERRORLEVEL%
1
D:\xyz\Prj>
==========
The message "return code..." is from inside my CMD script. The
"D:\xyz\Prj>echo %ERRORLEVEL%" is typed on command line, after
gradle.cmd has run: 1 => Return code was successfully passed to
caller.
Therefore I conclude that not all code paths are end with
System.exit(code!=0). Here the end of v0.4 org.gradleMain.main(): if
build.run() does not throw a exception, the error code returned to
caller will always be "0":
========================
/* 230*/ try
{
/* 230*/ Build build = Build.newInstance(startParameter);
/* 232*/ build.addBuildListener(exceptionReporter);
/* 233*/ build.addBuildListener(resultLogger);
/* 235*/ build.run(startParameter);
}
/* 236*/ catch (Throwable e)
{
/* 237*/ exceptionReporter.buildFinished(new BuildResult(null, e));
/* 238*/ exitWithError(options, e);
}
/* 240*/ exitWithSuccess(options);
========================
Regards,
Victor
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
