fixing run.bat and run.sh

[andrejserafim]

fixed #14423

I'm a little new to gradle, so do double check I haven't missed something basic.

[nik9000]

run.sh was good because it was "real". It run with the security manager and with bin/elasticsearch. So much real. Sadly this sacrifices a lot.

[andrejserafim]

Interesting, good to know, let me play around with these options. I took them from someone's configuration in the build-tools.

[rmuir]

I think its hard to reproduce the previous behavior without fixing #14361 first, but afaik, @rjernst is working on that right now.

at a high level: thats' what the previous code did: invoke the "integration test setup" but passing "fork=false", passing different port numbers (the conventional 9200/9300), and passing some additional jvm args to enable the remote debugger.

[andrejserafim]

I've removed the test argument, but the security manager has to stay disabled unfortunately.

Another way would be take the fresh distribution, unpackage, run. But that sounds like an overkill at this stage.

At least the run scripts will start a node, it can be improved on later.

[rjernst]

I think we should do this right, which means mimicking what we did before with maven. The framework is mostly already there, it just needs to be setup. This means creating a "run" task, which uses ClusterFormationTasks, and also stalls when the task is executed. Unfortunately, this won't work as nice until gradle fixes finalizedBy (https://discuss.gradle.org/t/run-finalizedby-when-task-is-interrupted-ctrl-c-continued-from-old-forum/12036), which means the cluster will remain alive until you run a follow up task...

[rjernst]

Note that the task should also not be under core, but at the root, or under distribution, since it will need to depend on the zip distribution.

[andrejserafim]

I was surprised it worked in core to be honest, I only put it there because I had classpath issues with the previous run task.

And now gradle is cheating on my behalf and I didn't even notice - it's gone off to the distribution module. Is there any way to enforce which modules should depend on which?

andrej@black:~/dev/elasticsearch/core$ gradle run
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes
:buildSrc:jar
:buildSrc:sourcesJar
:buildSrc:signArchives SKIPPED
:buildSrc:assemble
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build
=======================================
Elasticsearch Build Hamster says Hello!
=======================================
  Gradle Version : 2.8
  JDK Version    : 1.8.0_66-b17 (Oracle Corporation)
  OS Info        : Linux 3.19.0-31-generic (amd64)
:core:compileJava UP-TO-DATE
:core:processResources UP-TO-DATE
:core:classes UP-TO-DATE
:core:jar
:distribution:zip:buildZip      <-------------- 
:core:run#setup
:core:run#clean
:core:run#configure
:core:run#start

[rjernst]

It's not cheating. The cluster formation tasks add a dependency on the zip distribution. It's doing exactly what is expected. I just think it is confusing to have core depend on distribution (since it looks like a circular dep, even though it isn't in this case). So I would move the run task to either the root (my preference for ease of use) or distribution.

[andrejserafim]

I've moved it to distribution, since if I move it to the root it can't find the zip.

* What went wrong:
Could not resolve all dependencies for configuration ':elasticsearchZip'.
> Cannot resolve external dependency org.elasticsearch.distribution.zip:elasticsearch:3.0.0-SNAPSHOT because no repositories are defined.
  Required by:
      org.elasticsearch:elasticsearch:3.0.0-SNAPSHOT

Is there something I can configure to make it work? - first time I'm working with gradle.

[rjernst]

It tells you exactly the problem:

Cannot resolve ... because no repositories are defined.

However, rather than adding repositories to the root project, I think defining it under distribution is fine. We can even add a shortcut I think from the root file:

task run(dependsOn: ':distribution:runZip')

[andrejserafim]

rebasing to master, uhh, that generated a lot of commits on the pr.

[rjernst]

I think you just need to pull the latest master? Also, can you remove the run.sh and run.bat scripts? I don't think they are useful now (before they were saving from typing a complicated mvn command).

[rjernst]

@andrejserafim This looks good, can you sync up with master and I will merge?

[andrejserafim]

And done.

[rjernst]

@andrejserafim, sorry to ask one more thing. I hadn't realized how many small noisy commits there are here. Can you rebase on master so there is one commit with a clear commit message?

[andrejserafim]

@rjernst anything else?

[rjernst]

Thank you @andrejserafim!!