[Scala][client] Rename script, sample folder, template dir

[ackintosh]

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.1.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

Related issue: Adjust the names (script, sample folder, generator) to lang option · Issue #138

This PR adjusts the names (script, sample folder, template dir) to lang option (scala-akka scala-httpclient) to avoid users/contributors be confused.

Server generator improvement will proceeded in another PR.

[ackintosh]

technical committee: @clasnake @jimschubert @shijinkui @ramzimaalej

[jimschubert]

This would be a breaking change, so I think it would have to get merged into the 4.x branch.

[jmini]

@jimschubert: we definitively needs to write the rule for breaking change. If I quote you:

1. I wouldn't consider X a breaking change unless it would cause custom templates with by users to break.
2. I'd consider X a breaking change as users will no longer be able to generate X code without modifying existing code.

I do not think that the location of the sample dir src/main/resources/akka-scala => src/main/resources/scala-akka-client is a breaking change. I hope that nobody rely on this hardcoded in its code...

Location of the samples (output dir in the *.sh script) can also be changed.

For me it can be made even for in a weekly release (on master branch).

---

(I did not verify this change in detail)

Why are the CI jobs failing?

[jimschubert]

@jmini

Let me clarify why I think it would be a breaking change. If someone created a jar, extending any of these modified classes but relying on the old template locations, their modified classes would break. Remember, users can pass a fully qualified type as --generator-name. In this case, they'd need to modify the pre-built artifact to successfully generate.

Without telemetry, we're only guessing if that's even being used.

It's true that this wouldn't break built-in generators with or without custom templates. If we want to make an exception about the pre-built extensions, I'm cool with that. I would imagine that anyone compiling Scala from a pre-built extension would see the error and immediately know how to resolve it, so it's likely not a huge deal in this case.

[wing328]

The CI failures are due to change of the folder name. I'll fix it shortly to push to ackintosh:rename-scala-client

[wing328]

The shippable build failure below has nothing to do with this change:

===> Compiling jesse
===> Compiling _build/default/lib/jesse/src/jesse_tests_util.erl failed
_build/default/lib/jesse/src/jesse_tests_util.erl:92: erlang:get_stacktrace/0: deprecated; use the new try/catch syntax for retrieving the stack backtrace

I'll look into that separately instead if the issue also occurs with master.