Floren dev

[florendg]

This is a fix for issue #25. I added a task runTestar which makes it possible to run TESTAR using gradlew.
This solution runs TESTAR from the folder created by the task installDist. I also applied the debug strategy explained by @carlosengers in his post on issue #25.

[ferpasri]

The command "gradlew runTestar" works correctly for me from cmd, not appears in eclipse gradle tasks.
If I use the "run" of the eclipse gradle tasks, I still have the problem of having to move the files from the "scripts" folder

Carlo's code task works well for me to use "run":
task prepareRunFromEclipse (type: Copy){
from 'target/scripts'
into '.'
}

[carlosengers]

Hi Floren, Fernando,
I think i have a proposal that can serve the concerns.
in the build.gradle, replace the runTestar task with:
task runTestar(type: JavaExec) { group = 'custom_testar' description = 'run' workingDir 'target/scripts' classpath = sourceSets.main.runtimeClasspath main='org.fruit.monkey.Main' }
and remove :
runTestar.dependsOn(installDist)

alternatively:
leave runTestar.dependsOn(installDist) and add: group = 'custom_testar' description = 'run' to the runtestar task as it is proposed by Floren.

option1 has a faster startup as there is not distribution task.
option2 runs in the same way as the genuine commandline and uses the same subfolders for output.
this can be seen as a some easier comprehension.
both options share the aspect: no sourcecode change.

i have a slight favor of option1.

[florendg]

I noted that the task I created didn't appear in Eclipse. Gradle support in Eclipse is still a bit strange.
Looking at the solutions proposed by Carlo I would opt for second option adding the group and description info to the existing task. As Carlo noted it is a little bit slower, but It uses the same execution path as the final product.

[carlosengers]

please add a few words in the readme.md that it can be run directly from within eclipse and that it uses the 'standard' way of starting testar. i.e. via TESTAR.BAT.
probably also good to mention that if the last run was using the DEBUG option, then the distribution will also require the debugger attached. without a remote debugger attached, the testar process stays dormant. (~ remember that the debug feature sits now also in the jar files)