Compilation fix for PPoPP'20

[ArikRinberg]

Fix compilation for artifact of PPOPP'20 Fast Concurrent Data Sketches,

[Eshcar]

Hi @leerho @AlexanderSaydakov @jmalkin ,

Could one of you please take a look at this short PR - the module cannot compile without this fix. We need this fix as part of the Artifact Evaluation process done following our paper on concurrent sketches being accepted to PPoPP. We would like the evaluation committee to be able to generate the jars themselves. The deadline is early next week. Appreciate if you can review and approve. Thanks, Eshcar

[leerho]

Because of your short deadline, I will let this PR go through. However, I do want to find out why TestNG needs to be in compile scope. This is rather harmless, as performance of characterization tests themselves is not critical. Nonetheless, it smells like some other kind of programming problem.

[Eshcar]

Thanks @leerho I assume you will complete the change you wanted to do in the memory dependency in a different PR - seems like the right thing to do.

[leerho]

@Eshcar @ArikRinberg

Ok, as I suspected, there were a number of places in "main" where TestNG was been called. Those have all been fixed. I tried "mvn clean test" against master and it fine.

There are some things I do want to mention:

Branches and Release Tags

A branch such as 1.1.X is not the same as a release tag 1.1.0. The "X" in the third place means that that brach may have numerous release candidates and releases on that same branch. The 1.1.X branch could contain tags 1.1.0-RC1, 1.1.0-RC2, 1.1.0, 1.1.1-RC1, 1.1.1, 1.1.2-RC1, 1.1.2, etc. Once the second digit changes, it must be on a new branch: 1.2.X. The third digit is reserved for bug fixes where the only change is the code to fix the bug.

If you want the exact code of a release, you must switch to the Release Tag for that release. Note that a Tag refers to a specific Git-hash, for example Memory release 1.2.0-incubating is tied to the git-hash 76038e8... If you can verify from your IDE that you are looking at the correct git-hash, then you know you are looking at the exact source for that release.

Release Jars

The formal definition of a release of Apache code is that it must be obtained from archive.apache.org. And for projects in incubation you will find datasketches under archive.apache.org/dist/incubator.

For our Java releases we also provide access to jar artifacts, as a convenience, from Maven Central using the Nexus Repository Manager. Go to repository.apache.org and search for "datasketches".

We highly recommend that users take advantage of the artifact jars at Maven Central instead of generating their own release jars. Yes it is possible, but why?

incubator-datasketches-characterization is not formally released.

The characterization code is constantly changing and somewhat independent of actual releases of the primary code repositories (-java, -memory, -hive, -pig, etc.).

If you want a user to run a specific test with a specific configuration file, you could identify the git-hash for the specific commit that has the code you want and then instruct the user to pull against that git-hash. Or we could also create an annotated tag, that will make it a little easier, but essentially the same thing. (Now that we have these compile problems fixed! :) ) Another idea would be for you to create a jar of the characterization code at the git-hash point you want and send that to your reviewers.

[ArikRinberg]

Thanks for investigating this Lee. I am providing the artifact committee with JAR files, but for completeness I am providing them with a way to create them themselves. Thank you for explaining the 1.1.X branch, I have verified that all the jars work together with specific hash IDs.

I'm hoping that the committee will just use the provided JAR files, and save us the trouble of debugging their compilation.