Simplify and unify hazelcast-code-samples

[kwart]

I would like to open discussion about simplifying and unifying code samples. The idea behind is to provide unified experience to users and allow QE to verify the samples in a CI job.

Suggested improvements:

• use one main class per sample and unify its name across the samples (e.g. Main.java), so the maven-exec-plugin can be configured in the parent POM and users can use mvn exec:java in each sample
• shut down the whole cluster at the end of each sample
• remove shell scripts - the maven-exec-plugin shall be used instead (lets provide README.md where necessary)
• use System.out to print what the samples do
  • it will allow to introduce basic test automation in Jenkins

We should also think about slimming down the samples - i.e. find candidates for a removal. We have 214 modules with 312 main classes included now. Such amount is not easy to maintain. I would prefer to have 100 main classes at most.

Comments and suggestions for other improvements are welcome.

[Holmistr]

I would like to open discussion about simplifying and unifying code samples. The idea behind is to provide unified experience to users and allow QE to verify the samples in a CI job.

+1

use one main class per sample and unify its name across the samples

The key idea of the samples is to have it as simple as possible. Some of the samples have more simple classes with main methods. When you want to introduce just one per sample, you will have to merge it into one class -> the class will become bigger and even though there will be simple methods, it's not as beautifully readable as now. And we do not sacrifice readability here at any chance. However, I'm +1 for unifying the name

shut down the whole cluster at the end of each sample

Some of the samples are written the way that you start member and then you add clients and you can add as many clients as you want. Again, it's super simple and easily readable, separating member and the client, what needs to be done on server side and what on client side. Since it's separated this way, you cannot really shut it down easily after you're finished, because the (usually) member cannot really know, if you're finished.

remove shell scripts - the maven-exec-plugin shall be used instead (lets provide README.md where necessary)

+1

use System.out to print what the samples do

+1

I was going the same direction when I was reviewing the samples. Here I just listed a few things that came to consideration, maybe this time we will be able to find better solution :)